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n. REMARKS 

This amendment and reply is submitted in response to a "Final" Office Action (mailed on 
June 3, 2004). Applicants wish to thank the Examiner for having withdrawn all of the rejections 
raised previously. In this Final Office Action, the Examiner presented an entirely new rejection, 
one not previously presented, and one applicants have not previously addressed. 

Applicant thanks the Examiner for granting a telephone interview on Aug. 26, 2004 
regarding applicant's request that the finality of this rejection be withdrawn. During the 
interview, applicants' attorney presented the Examiner with a sunmiary of the material presented 
below in Sections B and C (pages 13-15) and requested an early telephone response fi-om the 
Examiner. Applicants' attorney has not yet received a response from the Examiner. 

Applicants respectfully request permission to respond fully to this new rejection, and also 
request withdrawal of the finality of this final office action for the reasons set forth below. 

A. Amendment to the Claims to Correct a Formal Defect 

Claim 3 1 has been amended by inserting the word "and" preceding the fmal paragraph of 
the claim. Applicants respectfully request entry of this amendment. This correction places the 
claims into better form for either allowance or for consideration on appeal. 

B. Applicants Request Permission to Respond to A New Rejection 

The Final Office Action contains an entirely new rejection of all the remaining claims (24 
to 42). This new rejection is based upon a new combination of two references neither of which 
previously has served as the basis for any rejection. (See page 20 of the Office Action mailed on 
November 19, 2003, where these two references were "made of record" but were "not relied 
upon.") 



-13- 



Atty. Dkt. No. 10015199-1 
A statement by the Examiner, which appears in the top three lines on page 3 of the Final 
Office Action, appears to contradict this. The Examiner begins his statement of the new 
rejection by saying: 

Previously presented claim 12 stands rejected under 35 U.S.C. 103(a) as being 
obvious over Weber USPN 5,812,668 (September 22, 1998) in view of Desgrousillers et 
al. USPN 5,715,373 (February 3, 1988). 

With all due respect, this is not true. The earlier rejection of claim 12 and of all the other 
claims before the Examiner previously was based upon the Kung U.S. Patent No, 5,295,230 
(March 15, 1994) either by itself or in combination with the published articles of Miller et al. 
(December 2000) and Atanasova et al. (July 2000). The Office Action mailed on November 19, 
2003 does not rely upon the Weber and Desgrousilliers, et al. patents to reject any of the claims. 

Accordingly, applicants have not previously been given an opportunity to address this 
new rejection and this new combination of references. That being the case, applicants 
respectfully request that the Examiner consider the arguments presented below as to why claims 
24 to 42 are patentable over this new combination of references. 

C. The Final Rejection is Premature and Should Be Withdrawn 

Applicants request reconsideration of the finality of the recent Final Office Action mailed 
on 6/3/2004. The final rejection is premature because it raises an entirely new grounds for 
rejecting all of the claims - a brand new rejection that is 29 pages long (pages 2 to 30 of the 
Final Office Action) and that contains approximately 240 separate applications of specifically 
cited prior art to individual claim elements. No similar rejection was ever made previously. 
This new rejection for obviousness is based upon the combination of two prior-art references 
neither of which was ever previously relied upon as the basis for any rejection. 

Applicants believe the finality of this rejection resulted because the Examiner mistakenly 
believed this same combination of two references had previously been cited against a previously- 
presented claim 12. In the Final Office Action, the Examiner says: 
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Previously presented claim 12 stands rejected under 35 U.S.C. 103(a) as 
being obvious over Weber USPN 5,812,668 (September 22, 1998) in view of 
Desgrousilliers, et al USPN 5,715,373 (February 3, 1998). [Office Action dated 
6/3/204, page 3, lines 1-3] 

With all due respect, this is an incorrect assumption on the part of the Examiner. In the 
earlier Office Action dated 1 1/19/2003, The rejection of claim 12 actually read as follows: 

Claims 1-14 and 17-23 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Kung U.S. Patent Number 5,295,230 (March 15, 1994) [Office 
Action dated 11/19/2003, page 10, lines 8-9] 

Accordingly applicant requests that the Final Rejection be withdrawn and treated as a 
non-final rejection so that applicants are given a full opportunity to respond to the 29 pages of 
entirely new grounds for rejection that have been raised by the Examiner. This response may be 
taken as applicant's response to that non-final rejection. 

The reason why applicants are requesting withdrawal of the fmality of this rejection is to 
give the Examiner plenty of time to carefully consider and respond to the arguments presented 
below, and to avoid the necessity of applicants filing a notice of appeal (or taking other 
equivalent action) just to keep this application alive. 

D. Rejection of Claims 24 to 42 Under 35 U.S.C. §103(a) 

All of the remaining claims 24 to 42 have been newly rejected for obviousness under 35 
U.S.C. §103(a) in view of the combination of U.S. Patent No. 5,812,668 {Weber) with U.S. 
Patent No. 5,715,373 (Desgrousillers et al.). Applicants respectfully request reconsideration of 
this rejection and allowance of claims 24 to 42 for the reasons set forth below. 

In subsections 1-5 below, applicants state general reasons, applicable to all of the claims, 
as to why the claims are allowable over the combination of Weber and Desgrousilliers, et al 

In subsection 6, applicants address the individual claims 24 to 42 in detail and respond 
with particularity to each one of the Examiner's approximately 240 individually-stated reasons, 
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each based upon a citation to a prior-art passage or figure, as to why the Examiner maintains 
particular claim elements can be found in the teachings of one or both of the Weber and 
Desgrousilliers, et al. patents. Subsection 6 concludes again that all of these claims are 
patentable. Subsection 6 reproduces and discusses individually every single one of the 
individual passages and figures found in these two prior art patents portions of which the 
Examiner has specifically cited in the 29 page rejection. Applicants will explain why none of 
these claims read upon any of these passages and figures. 

1. The Desgrousilliers, et al. Patent Is Not Relevant To The Present Invention. 
Desgrousilliers, et aL Relates To A Very Different Area of Technology - 
Testing a Program's Requirements Prior to Writing the Actual Program 

The Desgrousilliers, et al patent's teachings are unrelated to the teachings of the present 
invention. The Desgrousilliers, et al. patent relates to the testing of a program's design 
requirements prior to writing (or coding) the actual program, not to analyzing hardware and 
software configuration information collected fi-om fully programmed computers installed and 
operating normally in their normal operating environments. 

The Desgrousilliers, et al patent discloses method steps and system elements that may be 
used to test a computer program's design prior to the actual writing of the computer program. 
The patent teaches a programmer how to develop and then test a set of detailed requirements for 
a computer program long before the program is actually coded. This testing of requirements (not 
the testing of an actual program in operation) is carried out in a sheltered software development 
environment, and not in the field. Contrary to all this, the present application discloses method 
steps and system elements (recited in claims 24 to 42) that may be used to collect and then 
analyze data gathered fi-om fully programmed computers operating normally in the field. 

More specifically, the Desgrousilliers, et al patent teaches how the process of designing 
a type of computer program that the patent calls a "network management application" and also 
calls a "subsystem control facility (SCF)" program (abstract, lines 2-4) can be improved by 
developing and then testing a set of requirements prior to writing (or coding) the actual program. 
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With reference to Figure 8 of the patent, after a programmer has completed the initial design of 
an SCF program by developing the set of requirements, and before the SCF program is actually 
coded, the programmer prepares a "set of requirements for the proposed SCF" program that are 
"embodied in the form of a binary table [21 in Figure 8] which contains the subsystem control 
facility [SCF] command and display specifications" (col. 10, lines 52-58). These requirements 
are then "loaded into a test SCF unit 25" (col. 11, line 33) which tests the requirements under the 
guidance of test scripts (22 in Figure 8 and 14 in Figure 1) A "... knowledgebase development 
system 10 [shown in Figure 1 is] used [by the programmer] to generate test scripts [14, 28] ...." 
(col. 5, lines 27-31) After the SCF unit completes the testing of the requirements, the "test 
results files [are placed] in storage device 29" and may then be "manually analyzed" by the 
programmer (col. 13, lines 55-58), or they may "be analyzed by inference engine 16 [Figure 1] 
...." (col. 13, lines 52-53) 

All of this takes place in a sheltered software development environment, before the 
programmer begins any actual coding. This is emphasized at two points in the Desgrousilliers, 
et al patent's Summary of the Invention and also at both the start and at the end of the patent's 
Detailed Description: 

From a process standpoint, the invention comprises a method of preparing 
a suite of test scripts for testing a proposed subsystem control facility [SCF] set of 
requirements in a distributed system network prior to coding the proposed 
subsystem control facility, .... [ Summary, Col. 3, lines 52-56 - emphasis added] 

From an apparatus standpoint, the invention comprises a system for 
preparing a suite of test scripts for testing a proposed subsystem control facility 
[SCF] set of requirements prior to coding the proposed [SCF] design, .... 
[Summary, Col. 4, lines 15-18 - emphasis added] 

Turning now to the drawings, FIG. 1 illustrates a knowledgebase 
developmental system 10 used to generate test scripts for use in testing a 
proposed subsystem control facility [SCF] set of requirements prior to preparing 
actual software code for implementing the subsystem control facility [SCF]. 
[Start of Detailed Description, Col. 5, lines 27-31 - emphasis added] 
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As well now be apparent, the invention provides a comprehensive and 
consistent testing procedure which enables the selective preparation of a suite of 
test scripts tailored to a specific proposed subsystem set of requirements, which 
enables the developer/user to test the subsystem set of requirements without first 
coding the [subsystem control facility] SCF. [Next to final paragraph, Col. 16, 
line 66 to Col. 17, line 4 - emphasis added]. 

Contrary to this, the present invention as claimed in claims 24 to 42 is directed towards a 
method of and an apparatus for auditing operating computers and their computer programs while 
they are actually operating in the field. The present invention is thus not a software development 
tool. The present invention is a tool for auditing the operations of computers and computer 
programs while they operate normally. Accordingly, the teachings of the Desgrousilliers, et al. 
patent are not at all relevant to the present invention. For this reason, the claims are believed to 
be allowable over the combination of Weber and Desgrousilliers, et al 

2. The Weber Patent Is Also Not Relevant To The Present Invention. It Relates To 
A Different Area of Technology - Computerized Secure Payment 
Transaction Clearance Methods and Systems 

The Weber patent teaches the design of a distributed, Internet-based, merchant-to- 
customer secure payments transaction clearance method and system that utilizes such things as 
public-private encryption keys (col, 16, lines 22-25), Netscape's Secure Sockets Layer (SSL) 
protocol, and the Visa and-MasterCard Secure Electronic Transactions (SET) protocol to achieve 
an "on-line" cashless transaction clearing system which supports Internet shopping (col. 13, lines 
4-18). 

Briefly summarized and with reference to Figure IB (and also to col. 13, Imes 4-18), the 
Weber system works as follows: A customer's computer system 120 communicates over the 
Internet in a customer-merchant session (or linkage)^ 150 (secured by the SSL protocol) with a 
merchant's computer system 130 to pay for goods or services (for the details of this interaction, 
see Figure 28 and col. 138, line 14 to col. 139, line 48). To verify the customer's ability to pay, 



The Weber patent is inconsistent, speaking of the "customer-merchant session 150" and "customer- 
institution session 170" in coL 13, lines 4-18, and speaking of the "linkages 150 and 170" in col. 63, lines 54-57. 
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the merchant's computer system 130 communicates over the Internet in a customer- institution 
session (or linkage) 170^ (secured by the SET protocol) with a payment gateway 140, first to 
request (see Figure 4 and col. 16, lines 3-20) and then to receive back (see Figures 6A and 6B 
and col. 17 lines 20-27) authorization to accept the customer's payment, and then after accepting 
the payment, again to request the capture of the payment (see Figure 9 and col. 20, lines 10-22). 
The remainder of the patent simply explains in detail how this is done. 

The Weber patent thus teaches what hardware and what communications protocols are 
needed to enable a customer, a merchant, and a bank or other payment gateway to transfer funds 
fi-om a customer to a merchant with bank approval. In contrast to this, the present application 
and its clauns describe a system that runs in the background and monitors many different types 
of operating computer systems throughout an enterprise, collecting and analyzing hardware and 
software configuration information and then reporting issues that require the attention of system 
management. These two fields of technology are unrelated. For this reason, the claims are 
believed to be allowable over the combination of Weber and Desgrousilliers, et al. 

3. The Weber Patent's Limited Teachings Concerning System Testing Require 

Removal of the System from Normal Service, Not Background Monitoring of 
Normal Service 

There is brief mention in the Weber patent of system testing. The patent's abstract, 
summary, and claims are all directed to this relatively minor aspect of the overall disclosure. 

Weber^s testing of the merchant's computer system 130 (Figure IB) is not done in the 
manner taught by the present application. During Weber's testing, the merchant's computer 
system 130 is taken entirely out of service and cannot be used by customers wishing to make 
actual payments to the merchant. Contrary to this, the present invention audits computer systems 
unobtrusively from the background while the computer systems are fimctioning normally in the 
field. Weber's teachings in regard to testing are thus not relevant to the claims before the 
Examiner. 



2 

See footnote 1 page 26. 
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The merchant system testing aspect of the Weber patent's teachings is presented in the 
following passage, which refers to the merchant's computer system by its trademark, "vPOS": 

A bank distributes vPOS [a trademark name for the merchant system] via 
different sales channels. The first is direct fi*om a bank to an existing merchant with 
whom the bank already has an existing relationship. In this case, a version of vPOS 
already customized for a bank is sent to the merchant, either directly by a bank, or 
through a third-party distributor or service bureau. ... 

The more interesting case ... is where the potential merchant acquires, through 
some non-bank channel, a "generic" vPOS which has not yet been customized to interact 
with a specific bank. This vPOS can conraiunicate with a "test gateway", which the 
merchant may use to experiment with the various features of vPOS and to test the 
integration of the vPOS into a total online storefi-ont. ... 

In order to actually transact business over the Internet, the merchant must first 
obtain a merchant ID fi-om the merchant['s] bank with which he signs an acquiring 
agreement. For onlme payment processing, the merchant must also obtain an appropriate 
set of digital credentials in the form of public key certificates and possibly additional 
passwords, depending on the financial institution. Once these credentials are obtained, 
the merchant is ready to customize the already-obtained vPOS to communicate with a 
merchant bank's gateway. 

Using the built-in "serial number" certificate and the Test Gateway public key 
certificate (which is "hard-wired" into the vPOS software), it is possible to securely 
download a particular bank's customization applications to a specific copy of the vPOS 
software. Once the vPOS is appropriately configured, the last stage of customization 
download is to configure the vPOS so that it only responds to a public key certificate of 
the merchant's acquirer [bank]. This process is illustrated here in the context of a 
merchant who obtains a vPOS that talks to the VeriFone test gateway, and desires to 
customize the vPOS to interact with a gateway at a bank. [col. 61, line 28 to col. 62, line 
2] 

As this passage makes clear, this "off-line" testing procedure is not at all similar to the 
"on line" computer system auditing procedure described and claimed in the present application. 
For this reason, the claims are believed to be allowable over the combination of Weber and 
Desgrousilliers, et al 

4. Because They Relate to Different Fields of Technology, There Is No Motivation 
for One of Ordinary Skill in the Art to Combine the Teaching of the 
Desgrousilliers, et aL and Weber Patents 
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The Weber patent teaches how one may use computers to make payments securely over 
the Internet. It contains a brief passage which says that a merchant system may be taken out of 
service and tested while communicating not with the payment gateway of a bank but with a test 
payment gateway provided by the manufacturer of the merchant system. 

The Desgrousilliers, et al. patent teaches how one can develop and test a set of 
requirements for a network management application program using test data before the program 
is actually written or coded. 

With all due respect, applicants see nothing in either of these two patents that would 
motivate a computer scientist, after studying the teachings of both of these patents, to combine 
any of their teachings. The Desgrousilliers, et al. patent teaches only how the requirements for a 
program can be tested against test data long before the program is even written, and contrary to 
this the Weber patent teaches only how a normally operating merchant's computer system 
containing programs written long ago and actually operating can be tested as to the operating 
computer system's ability to handshake and communicate with a test or dummy bank computer 
that is substituted for the normal payment gateway computer of an actual bank. These teachings 
are not related in any way and are not combinable. 

The Examiner maintains, as to representative independent claim 24 (final office action 
mailed on 6/3/2004, page 5, lines 8-20) that there is motivation to combine these two references 
(in the passage quoted from the Office Action and set forth below, I have inserted all of the 
material cited by the Examiner at appropriate points for clarity): 

Motivation - The portions of the claimed invention would have been a highly 
desirable feature in this art for 

• Early correction of errors {Desgrousilliers et al, Abstract, 

"A method and system for preparing a suite of test scripts for testing a 
proposed network management application. The proposed network management 
application, termed a subsystem control facility (SCF), is first defined as a set of 
requirements with the aid of a developmental tool incorporating a subsystem 
knowledgebase and a test generation knowledgebase. The subsystem 
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knowledgebase contains the rules governing the operation of a given network and 
a library of permitted commands, objects, attributes, modifiers and other data. The 
test generation knowledgebase includes information relating to those conraiands 
and objects specific to the proposed subsystem control facility set of 
requirements. A user interface coupled to the knowledgebases permits the 
selection of types of tests and specific commands and objects to be tested. Once 
test selection has been specified, test scripts corresponding to the selected tests 
are generated from the first and second knowledgebases for use in testing the 
proposed set of requirements for the SCF prior to coding the SCF. The suite of 
test scripts can be used to test the proposed SCF set of requirements, detect 
nonconformance with the rules and permit modification of the proposed set of 
SCF requirements. If necessary, additional testing may be performed using the 
same test scripts or a subset thereof, until the test results indicate no errors and a 
minimum number of warnings. Thereafter, the SCF product module can be coded. 
Errors in the developmental stage can be thus corrected early in the 
developmental cycle.") 

Convenient and secure information exchange (Weber, column 2, lines 21-55, 

"To implement an automated, convenient transaction that can dispense 
some form of economic value, there has been a trend towards off-line payments. 
For example, numerous ideas have been proposed for some form of "electronic 
money" that can be used in cashless payment transactions as altematives to the 
traditional currency and check types of payment systems. See U.S. Pat. No. 
4,977,595, entitled 'METHOD AND APPARATUS FOR IMPLEMENTING 
ELECTRONIC CASH,' and U.S. Pat. No. 4,305,059, entitled 'MODULAR 
FUNDS TRANSFER SYSTEM.' 

"The more well known techniques include magnetic stripe cards 
purchased for a given amount and from which a prepaid value can be deducted for 
specific purposes. Upon exhaustion of the economic value, the cards are thrown 
away. Other examples include memory cards or so called smart cards which are 
capable of repetitively storing information representing value that is likewise 
deducted for specific purposes. 

"It is desirable for a computer operated under the control of a merchant to 
obtain information offered by a customer and transmitted by a computer operating 
under the control of the customer over a publicly accessible packet-switched 
network (e.g., the Internet) to the computer operating under the control of the 
merchant, without risking the exposure of the information to interception by third 
parties that have access to the network, and to assure that the information is from 
an authentic source. It is fiirther desirable for the merchant to transmit 
information, including a subset of the information provided by the customer, over 
such a network to a payment gateway computer system that is designated, by a 
bank or other fmancial institution that has the responsibility of providing payment 
on behalf of the customer, to authorize a commercial transaction on behalf of such 
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a financial institution, without the risk of exposing that information to 
interception by third parties.") 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made, to combine Weber with Desgrousilliers, et al to obtain the 
invention of claim 24, a computerized method for auditing the software or hardware 
configurations of a plurality of computers in one or more enterprises. The modification 
would have been obvious because one of ordinary skill in the art would have been 
motivated to quickly and conveniently detect as well as securely report errors within 
enterprise computer systems. 

The Examiner's position is thus that the present invention involves somehow combining 
the concept of correcting errors early, as illustrated by the Desgrousilliers, et al patent's 
teaching that a "set of requirements" for a program should be thoroughly tested before the 
program itself is written, with the concept of providing convenient and secure information 
exchange, as is illustrated by the Weber et al. patent's teachings that sensitive customer payment 
transactions should be sent fi"om customer to merchant to bank over the Internet in a secure 
manner. 

The problem with the Examiner's position as stated above is that the present invention, as 
described in the application and as claimed in the clauns, does not require nor teach these two 
concepts. It does not require nor teach that the requirements for a program should be thoroughly 
tested before the program is written; and it also does not require nor teach that all information 
sent over the Internet should be sent in a secure manner. Briefly summarized, the present 
invention (as defined in claim 24) does require and teach that hardware or software configuration 
information (or both) is to be collected from operating computers and is then to be analyzed by 
harnessing a list of specific analyzers, each containmg executable program steps, to 
configuration data collected fi-om a list of specific computers, the lists of analyzers and 
computers thus defining an audit task. The claims do not mention "early correction of errors," 
and the claims do not mention "convenient and secure information exchange." Accordingly, the 
two concepts listed by the Examiner and the two passages cited by the Examiner as illustrating 
these concepts and as demonstrating "motivation" are simply not relevant to the present 
invenfion as clahned. 
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Additionally, even if these two concepts and these two passages were relevant, they 
relate to entirely different topics of technology. Detecting and correcting errors earlier, rather 
than later, is an entirely different concept that is unrelated to the concept providing a convenient 
and secure information exchange. 

For both of these reasons, and with all due respect, the Examiner has not demonstrated 
any reasons why one skilled in the art to which the present invention pertains, mainly monitoring 
operating computers operating in the field, would be motivated to combine the teachings of a 
first patent's teachings on the testing of software requirements before the software is written with 
a second patent's teachings on how payments may be approved and made over the Internet. 
Hence, the claims are patentable over the combination of Weber and Desgrousilliers, et al. 

5. Testing Procedures Taught in the Weber and Desgrousilliers, et aL Patents Are 
Carried Out Only On Computers and Software That Are Not Operating 
Normally in the Field 

The present invention, as defined by all the claims, is a system or method for producing 
an audit report identifying issues of concern to management arising in computers that are 
operating normally in the field. The PCs are being used by users for word processing, Internet 
exploring, and any number of other uses. The servers are running a wide variety of applications, 
accepting requests from client computers and responding, all in the normal manner. Meanwhile, 
configuration information is being gathered and analyzed and audit reports listing issues are 
being generated, all in the background, without the computers having to be taken out of service. 

Contrast this with the teachings of the Weber patent, where a merchant's system for 
accepting and processing payments received from customers must be taken out of service - 
disconnected from the bank's payment gateway host and connected instead to a test version of 
the payment gateway - so that testing can be carried out. Contrast this with the teachings of the 
Desgrousilliers patent, which teaches testing only of a program's requirements and not testing of 
the actual program itself, much less testing of the program while it operates normally. 
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Because neither the Weber nor the Desgrousilliers, et al patent teaches gathering data 
from computers while they are operating normally and then analyzing that data, neither is 
relevant to any of the claims before the Examiner. For this reason, the claims are over the 
combination of Weber and Desgrousilliers, et al, 

6. The Claims, Considered Individually and Element by Element, Are Patentable 
Over The Combination of Weber and Desgrousilliers, et aL 

Applicant thanks the Examiner for having taken the time to point out precisely what 
elements in which Figures and what textual passages in each of the two cited reference patents is 
relevant to the individual elements of each claim. With all due respect, and keeping in mind the 
discussion presented above as to the general nature and purpose of the prior art and how it differs 
from the teachings of the present application, applicants still maintain that each and every claim 
remains patentable. Their allowance is again respectfijUy requested on the basis of the detailed, 
element-by-element and prior art passage-by-passage discussion which follows. 

In the discussion that follows, the elements of each claim are referred to as the 
"preamble," the "first element," the "second element," and so on. In the actual claims 
reproduced above on pages 10 to 20, paragraph breaks within each claim separate the claim's 
"preamble" from its "first element," separate its "first element" from its "second element," and 
so on. For example, the "second element" of claim 24 is the passage "providing ... computer:" 
which begins and ends with a paragraph break and which is preceded by the claim's preamble 
("A computerized ... steps of:") and by the claim's first element ("in a fully ... both;"). 

The Examiner's new rejection under 35 U.S.C. §103 is 29 pages long, and it contains 
approximately 240 specific citations of prior art passages or figures, each cited against a specific 
element of one of the 19 claims. The Rules require applicants to "... reply to every ground of 
objection and rejection in the prior Office action." (37 CFR §1. 111(b)) Accordingly, the 
response which follows, and which addresses each of the Examiner's rejections individually, is 
of necessity quite lengthy. 
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Applicants have made every effort to keep this response as short as possible, first by 
limiting the discussions to representative claims and claim elements whenever possible and by 
then indicating to which other elements of which other claims each discussion is applicable; and 
secondly by referring back to arguments presented previously rather than repeating the 
arguments wherever possible. In this manner, applicants have been able to respond to the 
Examiner's 29 page '103 rejection in only 62 pages of discussion (presented starting below, 
pages 34 to 96). 

Since applicant's three claim sets, claims 24-29 and 30 (method), claims 31-36 and 37 
(system), and claims 38-41 and 42 ("means for" system), correspond fairly closely in the way 
that they define the invention, the discussion below will focus upon only one of these three claun 
sets. Applicants will present below a lengthy and detailed discussion of claims 24 -29 (method), 
discussing them in the context of virtually all the prior art passages that the Examiner has cited 
against any claim. The discussions will each point out the corresponding elements of the 
remaining claims 31-36 and 38-41 to which the same discussion is applicable whenever this is 
appropriate. The discussion of the claims 3 1-36 and 38-41 will then be kept as short as possible 
by focusing only upon rejections unique to these claims. The three narrower independent claims 
30, 37, and 42 will not be discussed individually in detail, since their individual elements parallel 
very closely the individual elements of the other claims 24-29, 31-36, and 38-41. 

a. Claim 24 is Patentable Over The Combination of Weber and 

Desgrousilliers, et aL Claims 31 and 38 Are Also Patentable for the 
Same Reasons 

Method independent claim 24 corresponds to and parallels system independent claim 3 1 
and "means for" system independent claim 38. (Claim 38 includes additional language that 
corresponds to and parallels language contained in dependant claim 25, and accordingly a 
discussion relevant to that additional language of claim 38 is postponed to the discussion of 
claim 25, presented later on.) Accordmgly, all the reasons presented below supporting the 
patentability of claim 24 are equally applicable to the claims 31 and 38. 



-26- 



Atty. Dkt.No. 10015199-1 
Briefly summarized, the present invention as defined in claim 24 requires and teaches 
that hardware or software configuration information (or both) is to be collected fi"om operating 
computers and is then to be analyzed by harnessing a list of specific analyzers, each containing 
executable program steps, to configuration data collected fi-om a list of specific computers, the 
lists of analyzers and computers thus defining an audit task. The analyzer's executable program 
steps compute and then present reports identifying significant issues, and these reports are then 
utilized by management for audit purposes. 

The elements of claim 24 will now be discussed individually, and in the same order in 
which they were addressed by the Examiner, to the extent feasible. The discussion presented 
here of claim 24 's elements is also applicable to the elements of claims 31 and 38 as well. 

i. The First Element of Claim 24 Does Not Read Upon Weber 

The Examiner indicates that the first element of claim 24, when modified as indicated 

below: 

in a largely feUy automated manner, collecting fi-om each of a plurality of 
networked computers configuration information defining each computer's 
software configuration or hardware configuration or both;"' 

reads upon the following passage ~ the Weber patent's Abstract: 

ABSTRACT 

An architecture for verifying the operation of a remote transaction 
clearance system is disclosed. A merchant-controlled computer communicates 
with a test gateway computer over a communications channel. The test gateway 
computer responds with simulated transaction responses. In another aspect of the 
invention, the transaction responses include configuration data that is used by the 
merchant-operated computer to configure itself to access a production gateway 
computer. 



For discussion purposes only, the Examiner modified this claim language, replacing "fully" with 
"largely" ~ see page 3, line 6, of the Final Office Action mailed on 6/3/2004, and compare the Examiner's wording 
of this passage with the first element of claim 24 as set forth on page 2 of this reply. 
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The second and third sentences in this passage describe a merchant's computer system 
that can be tested by sending test payment transaction information not to a bank's host computer 
but to a "test gateway" which responds as if it were a bank's host computer — but the test 
gateway simply sends back dummy responses. The data being transferred here is not hardware 
or software "configuration information," as is requu"ed by the first element of claim 24. The data 
is dummy or test payment transactions. Clearly, this first element of claim 24 clearly does not 
read upon the first three sentences in this passage. 

The final sentence of this passage speaks of sending configuration data to the merchant's 
computer, not of collecting configuration information from the merchant's computer. This is 
done to reconfigure the merchant's computer out of its "default" configuration, in which it only 
communicates payment information to a test host computer, and into the configuration that is 
required by a particular bank's host computer so that the merchant's computer system may 
thereafter communicate payment information to that particular bank's host computer. This final 
sentence does mention configuration data, but the configuration data mentioned is flowing 
towards the merchant's computer to reconfigure that computer ~ it is not being collected from 
the merchant's computer, as the claim language requires. Because the first element of claim 24 
specifically calls for the "collection" of "configuration information", and not the dissemination 
of such information to reconfigure a computer in the field, the first element of claim 24 clearly 
does not read upon this final sentence. 

The Examiner further indicates that the furst element of claun 24 also reads upon the 
following passage taken from the Weber patent: 

The unique architecture of the Cardholder 120, Merchant 130 and 
Gateway 140, as shown in FIG. IB, provides communication capability between 
the modules utilizing the Internet to support [sessions or] linkages 150 and 170. 
Since the Internet is so pervasive, and access is available from virtually any 
computer, utilizing the Internet as the communication backbone for connecting 
the cardholder, merchant and access to the authorizing bank through a gateway 
allows the merchant vPOS software to be remotely located from the merchant's 
premises, [col. 63, lines 54-63] 
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The sessions (or linkages'^) 150 and 170 discussed here are each defined by handshake 
protocols. The session (or linkage) 150 (discussed above on pages 25-26) is a secure Internet 
handshake that takes place between the "cardholder" or customer's system 120 and the 
merchant's system 130 to implement an "I want to pay for a purchase" handshake. (This 
handshake protocol is fiiUy described in Figure 28 of the Weber patent.) The session (or Imkage) 
150 is thus not a session that collects "configuration information defining each computer's 
software configuration or hardware configuration or both" as is required by the first element of 
claim 24. It is, instead, a session that enables the customer to offer to pay, and it enables the 
merchant to accept payment. The claim language clearly does not read upon this passage with 
respect to the session (or linkage) 150. 

The session (or linkage) 170 (also discussed above on pages 25-26) is a secure Internet 
handshake session that takes place between the merchant's system 130 and the payment gateway 
140 to implement a "can I accept payment fi-om this customer" handshake session. (The 
handshake protocol is fiiUy described in Figure 4, Figures 6 A and 6B, and Figures 12 A and 12B 
of the Weber patent.) The session (or linkage) 170 is thus also not a session that collects 
"configuration information defining each computer's software configuration or hardware 
configuration or both" as is required by the first element of claim 24. It is, instead, a session that 
enables the merchant to obtain permission from the bank (the payment gateway) to accept 
payment and to later request "capture" of the payment. The claim language clearly does not read 
upon this passage with respect to the session (or linkage) 170. 

The Examiner also indicates that the first element of claim 24 reads upon the following 
additional, rather lengthy, passage taken from the Weber patent: 

A Data Manager provides storage and retrieval of generic data items and 
database records. It is assumed that data fields, index fields or entire data records 
can be marked as encrypted and the encryption process is largely automated. The 
data manager has no specific knowledge of database records appropriate to 



^ The Weber patent is inconsistent, speaking of the "customer-merchant session 150" and "customer- 
institution session 170" in col. 13, lines 4-18, and speaking of the "linkages 150 and 170" in col. 63, lines 54-57. 
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different payment methods. This layer is separated out so as to reduce changes 
required when new payment methods are introduced. However RSA key pairs and 
certificates might be considered as "simple" data types. This component also 
provides an abstraction which supports wallet files on computer disk or contained 
in smart cards. 

The Open Data Base Connectivity (ODBC)/Java Data Base Connectivity 
(JDBC) component provides Data Base Connectivity where formal database 
components are required. An embodiment of the Smart Card Wallet allows wallet 
data to be stored and/or secured by a cryptographic token. 

A preferred embodiment includes a single file or directory of files 
comprising a "wallet" which contains personal information and mformation about 
multiple payment methods with the preferred implementation. These payment 
methods (Visa cards, debit cards, smart cards, micro-payments etc. ) also contain 
information such as account numbers, certificates, key pairs, expiration dates etc. 
The wallet is envisaged to also contain all the receipts and transaction records 
pertaining to every payment made using the wallet. A Cryptographic API 
component provides a standard interface for RSA and related cryptographic 
software or hardware. This support includes encryption, signature, and key 
generation. Choice of key exchange algorithm, synmietric encryption algorithm, 
and signature algorithm should all be configurable. A base class stipulates generic 
behavior, derived classes handle various semantic options (e.g. software based 
cryptography versus hardware based cryptography.) [col. 137, line 26-63] 

This passage is pulled from a discussion of "Certificate Processing," where the point is 
made that the merchant needs to obtain reassurance that the "cardholder" has a valid card, while 
the "cardholder" needs reassurance that the "merchant" is authorized by the bank to accept 
payment. This particular passage discusses various aspects of a "wallet" feature, where the 
"wallet" is a secure data set that contains credit card numbers and other confidential personal 
mformation of the "cardholder." This passage also discusses security techniques for managing 
such information. 

But this passage contains no mention of the "collecting" of "configuration information 
defming each computer's software configuration or hardware configuration" as is required by the 
first element of claim 24. The claim language clearly does not read upon this passage. 
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Accordingly, the first element of claim 24 does not read upon any of the passages in the 
Weber patent which the Examiner has pointed out. Neither do the corresponding first, second, 
and third elements of claim 3 1 and the corresponding first, third, and fourth elements of claim 
38. 

ii. The Second Element of Claim 24 Does Not Read Upon Weber 

The Examiner indicates that the second element of clahn 24: 

providing a plurality of analyzers bas e d on e xp e rt knowl e dg e ^ each 
analyzer comprising the executable program steps needed to compute, from 
selected configuration information gathered fi'om a single computer, a report 
identifying at least one issue relating to the computer; 

reads upon the last sentence in the following passage of the Weber patent (the entire 
passage is reproduced, rather than just the last sentence cited by the Examiner against claim 24, 
because the Examiner later cited this entire passage against the independent system claims 31 
and 38): 

Transaction Performance Monitoring and Measurement 

The "hits" performance indicators are available from the Web server. 
Statistics can be generated at any time to highlight the load pattern or to pinpoint 
the time when the server was most active. 

Gateway statistics about transaction requests (by transaction type) and 
transaction resuhs (e.g., success, failed due to host, failed due to authentication, 
etc.) can be determined at any time for a particular time interval by generating a 
report, [col. 124, lines 9-18] 

This passage is taken from a later section of the Weber patent that describes the front end 
portion of the payment gateway 140 (Figure 2). The payment gateway 140's front end is called 



^ For discussion purposes, the Examiner left the phrase "based on expert knowledge" out of this claim 
element when reproducing the language of this claim element m the rejection (Final Office Action mailed on 
6/3/2004, page 3, line 12) to indicate that the Examiner did not find anything in the Weber patent that anticipated 
this particular phrase. The phrase is shown here stricken through. The Examiner, at a later point in the Final Office 
Action (page 4, line 9), addresses this phrase in the context of the Desgrousilliers, et al patent. 
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an "Internet transaction gateway." This "gateway" un-encrypts and transforms transactions 
received from merchant systems 130 over the Internet into a different format, a format which an 
accepting bank's "legacy processor" host computer can accept - a transaction format essentially 
identical to what is generated by today's merchant credit card scanner boxes and delivered by 
telephone to such a legacy processor bank host computer. (See col. 1 19, lines 13-42 - the 
"Internet transaction gateway" appears in Figure 21.) 

This Internet transaction gateway "provides logging, monitoring, reporting, and system 
administration" functions, (col. 120, line 19 and lines 35-36) It includes a transaction logger 
2150 (Figure 21) which passes records via a database server 2160 to capture transaction logs in a 
database 2180. These transaction logs contain data concerning each transaction, where a 
transaction is a payment request from a merchant's computer system sent to an accepting bank's 
host computer, a payment capture request from a merchant's computer system sent to an 
accepting bank's host computer, or a response to such requests sent back to the merchant's 
computer system from the accepting back's host computer. These transactions contain 
information such as the identity of the customer, the credit card number, the amount of the 
transaction, etc. These transactions do not contain configuration information defming some 
computer's software configuration or hardware configuration, as the first element of claim 24 
requires. 

The above passage pointed out by the Examiner simply says that this Internet transaction 
gateway also includes some type of computer program which, when provided by an operator 
with a time range, can generate for that operator statistics concerning the percentage of payment 
request transactions that were honored and the percentage of payment transactions that were not 
honored for various reasons. 

This Internet transaction gateway computer program does not comply with specific 
requh-ements set forth in the second element of claim 24: This computer program does not 
"compute, from selected configuration information gathered from a single computer, a report 
identifymg at least one issue relating to the computer". First, this program cannot generate such 
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a report because this program does not receive as input data any software or hardware 
configuration information - it receives as input data only payment transaction mformation. 
Secondly, this program does not compute a report identifying issues relating to a specific 
computer - it computes reports relating to customer-merchant payment transactions and their 
successful or unsuccessful processing. Accordingly, the claim language clearly does not read 
upon this passage. 

The Examiner further mdicates that the second element of claim 24 also reads upon the 
following passage taken from the Weber patent: 

Analyze SetRequest 

FIGS. 52A and 52B describe the AnalyzeSetRequest routine. This routine 
is by Step 51 10 as illustrated in FIG. 51. Execution begins in Step 5200. In Step 
5205 the various fields in the SET record are obtained, as will be more fiiUy 
disclosed below with respect to FIGS. 56A and 56B. In Step 5210 the Gateway 
checks the retry count. A retry count is zero indicates that the request being 
analyzed is a new request, and control proceeds to Step 5212, indicating a new 
request. If the retry account is non-zero, this means that the request is a retry of a 
prior request, and control proceeds to Step 5214 where a retry is indicated. 

Following either step 5212 or 5214, execution proceeds to Step 5215. In 
Step 5215 the Gateway checks to see whether the request represents a "stale 
request," as will be more fully described below with respect to FIG. 57. In Step 
5220, the Gateway tests the result of the stale check from Step 5215. If the request 
is stale it is marked as stale in Step 5222. Otherwise the record is marked as not 
stale in Step 5224. Following either Step 5222 or Step 5224, control proceeds to 
Step 5230. In Step 5230 a message representing the SET request is inserted into 
the database for tracking purposes, and control proceeds to Step 5240. 

In Step 5240 the Gateway checks to see if the request had been marked 
stale in Step 5222. If so, it proceeds to Step 5242, exiting with an error condition. 
In Step 5245, the Gateway attempts to retrieve from the database a message 
corresponding to the current SET request, .... [col. 142, lines 32-59] 

To understand this passage, one must first understand the meaning of the word "SET" 
and the phrase "SETRequest" both of which appear this passage. 
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"SET" means the "Secure Electronic Transfer" protocol adopted by Visa and 
MasterCard, (col. 2, lines 58-64) Referring to Figure 3, the Weber patent teaches that the "... 
session 170 [which occurs between the merchant's computer system 130 and the payment 
gateway computer system 140] operates under a variant of a secure payment technology such as 
the SET protocol ...." (col. 13, lines 14-18) 

The patent notes that all the transactions originate with the merchant's computer system 
130, and not with the gateway computer system 140 (col. 13, lines 14-18). Accordingly, it is 
appropriate to think of every transaction as being a "request" made to the gateway computer 
system 140. From this it can be seen that a "SET request" is simply a request (or transaction) 
initiated by a merchant's computer system 130, formulated using the Visa-MasterCard "SET" 
protocol, and sent to the payment gateway computer system 140 which passes it on to the host 
computer system of the merchant's acquiring bank.^ 

The fiill title of the above passage, ''AnalyzeSetRequcst,'' is the name of a computer 
program or routine. The above passage is the first part of an explanation of what this program or 
routine does. Before this passage can be fiiUy understood, the environment within which this 
program or routine operates needs to be explained. This environment will be described in the 
next three paragraphs, and then an explanation of this program will be presented. 

It will be recalled from discussions presented above that the gateway computer system 
140 includes an Internet Transaction Gateway (shown in Figure 21) and the bank's host 
computer system (not shown). All requests and all replies to requests pass through this Internet 
Transaction Gateway when traveling between the merchant's computer system 130 and the 
bank's host computer system. Transmissions to and from the merchant's computer system enter 
and leave this Gateway at a secure server 2102 (Figure 21) (which connects to the public 
Internet), and transmissions to and from the bank's host computer system enter and leave this 

^ As used in the Weber patent, the temi "request" (judged from the context of usage within the JVeber 
patent) nomially includes by implication both an initial request message sent out by the merchant's computer system 
and also any related reply message made in response to this request by the bank's host computer system. Thus, the 
request message and any reply message appear to be included in the term "request" as used here. 
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Gateway at a socket TCP multiplexer 2130 (Figure 21) (which connects to a private network link 
2140 leading to the bank's host computer system). Decryption of all requests received from the 
merchant's computer system 130 and encryption of all replies sent back to the merchant's 
computer system 130 take place at 2120 (Figure 21) within this Gateway. 

The remaining steps carried out on requests and replies by this Gateway are shown in 
Figure 51. Decrypted requests received from a merchant's computer system 130 are translated 
into the Bank's format (the "forward translate" step 5135) and are then sent on to the bank's host 
computer system (the "host communication" step 5 145). When the bank's host computer system 
provides a reply, that reply is translated back into the merchant computer system's format (the 
"reverse translate" step 5155) and is then encrypted and sent back (the "proceed to respond" step 
5120) to the merchant's computer system 130. 

Figure 51 illustrates and includes a program "looping" process, where each request and 
its associated reply (if any) is processed by at least four repetitive passes around the program 
control loop defined by the four test steps 5120, 5130, 5140, and 5150, taking a different branch 
5135 (forward translate), 5145 (host conununication), 5155 (reverse translate), and 5120 
(proceed to respond) diu-ing each pass around this loop to complete all the necessary tasks. 

The AnalyseSetRequest program, described in the above passage that was cited by the 
Examiner, appears at step 5 1 10 in this same Figure 5 1 . The figure is not drawn correctly - the 
program control loop just described should pass through this AnalyzeSetReqxxtst program 5110, 
and not bypass it. During every pass around this loop, the AnalyseSetRequest program 51 10 is 
called upon to examine or analyzes the request and any associated reply, and then the 
AnalyzeSetReqn^st program 5110 sets the necessary software switches to control which of the 
steps 5135 (forward translate), 5145 (host communication), 5155 (reverse translate), and 5120 
(proceed to respond) the request or reply is subjected to during the next pass around the program 
control loop shown in Figure 51. 
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The above passage cited by the Examiner is thus a description of a computer program 
that periodically analyzes data associated a merchant computer system's requests, and possibly 
also with a corresponding bank host computer system's replies to these requests. This program 
then makes a decision based on this analysis as to what processing these requests (and 
sometimes also these replies) are to be subjected to next. Should the next step performed be 
forward translation of the request from the merchant computer system's data format into the 
bank host computer system's data format? Should the next step performed be sending the 
translated request on to the bank's host computer system? Should nothing be done with this 
request, since we are awaiting a reply from the bank's host computer system? Has excessive 
time elapsed, so that an error should be declared and the processing of this request and any reply 
should be aborted? This is the type of analysis that the program "Analyze SetRequest" performs, 
and this is what is described in the above passage which the Examiner maintains the second 
element of claim 24 reads upon. (For further details, see the overview flowchart of this 
AnalyzeSetRequQst program that is presented in Figures 52A and 52B and the accompanying text 
of the patent, col. 142, line 32 to col. 144, line 31. An actual program listing appears in columns 
144 and 145.) 

This passage cited by the Examiner does describe a computer program 51 10 containing 
executable program steps, and this program 5110 does perform some form of analysis. But this 
program 51 10 does not receive as its input data "selected configuration information gathered 
from a single computer" as the second element of claim 24 requires, and it also does not 
"compute" from such information "a report identifying at least one issue relating to the 
computer" from which the configuration information was gathered. In addition, and with 
reference to the first element of claim 24, the "configuration information gathered" must defme 
the "computer's software configuration or hardware configuration or both." But the only data 
gathered by the Internet Transaction Gateway and subjected to analysis by its AnalyzeSetRequ&st 
program 5 1 10 is data defining the status of requests to authorize a merchant to receive a payment 
from a customer and a subsequent request to capture that payment and the like, as has been 
explained. 
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The claim language of the second element of claim 24 clearly does not read upon this 
passage in any way. Accordingly, the second element of claim 24 does not read upon any of the 
passages cited by the Examiner. Neither does the corresponding fourth element of claim 31, and 
neither does the corresponding fifth element of clahn 38. 

iii. Third Element of Claim 24 Does Not Read Upon Weber 

The third element of claim 24 is a method step which calls for: 

defining at least one task definition comprising a list of one or more of 
said computers and a list of one or more of said analyzers;^ 

This third element of claim 24 calls for a "task definition" that defines a specific auditing 
task. An auditing task is an order that is presented to an auditing computer system ordering it to 
examine configuration information gathered fi-om a specific list of computers by processing that 
information using the executable program steps included in a specific list of analyzers. The task 
definition lists the computers which are to be audited, and it lists the analyzers whose executable 
program steps are to carry out this analysis. With reference to the present application, a task 
definition system 810 appears in Figure 8 of the present application. It includes an assessment 
task 814 that contains a list of nodes (which term includes computers) and a list of analyzers, as 
is shown in Figure 8. 

The Examiner indicates that this third element of claim 24 reads upon the following 
passage taken fi-om the Weber patent: 

... The vPOS configuration setup fiinction is used to setup the vPOS 
configuration data. The vPOS configuration data is divided into different tables, 



For discussion purposes only, the Examiner, in his final rejection, presented this passage not as it is 
shown here, but in an altered form that completely omitted the two occurrences of the phrase "a list of (see page 3, 
lines 17-18 of the Final Office Action mailed on 6/3/2004, and compare to the third element of claim 24 set forth on 
page 2 of this reply). With all due respect, applicants object to this alteration of this claim language, even for 
discussion purposes, since revising this passage in this manner requires a *task definition" to contain "computers" 
and "analyzers" rather than simply to contain "a list of ... computers and a list of ... analyzers." Accordingly, this 
change clearly alters the substantive meaning of this entire passage in a way that changes the substantive scope of 
the claim and also renders this passage meaningless in the context of the present invention. 
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for example, the Card/Issuer Definition Table (CDT), the Host/Acquirer 
Definition Table (HDT), the Communications Parameters Table (CPT) and the 
Terminal Configuration Table (TCT). ... [col. 39, lines 13-19] 

This passage is taken fi-om three paragraphs (col. 38, line 59 to col. 39, line 25) of the 
Weber patent that list the various software fimctions a merchant can call upon to perform tasks 
relating to the merchant's computer system 130 (referred to in this passage by its trademark 
name "vPOS"). The "configuration setup fiinction" discussed in this passage permits the 
merchant to adjust certain merchant computer system configuration information values that are 
stored within the merchant's computer system and that form a part of its software configuration. 
These configuration information values include: 

1. A Card Issuer Defmition Table (CDT), which contains information 
specific to each credit card issuer (Visa, MasterCard, etc.).^ 

2. A Host/Acquirer Definition Table (HDT), which contains Information 
specific to the merchant's acquiring bank ("acquirer") and to that bank's host 
computer system ("host").^ 

3. A Communications Parameter Table (CPT), which contains additional 
Information also specific to the merchant's acquiring bank ("acquirer") and to 
that bank's host computer system ("host").^^ 

4. A Terminal Configuration Table (TCT), which contains only two 
values: the merchant's name (col. 41, lines 7-8) and a "Lock Flag" that signals 
whether the merchant's computer system is "locked" or "unlocked." (col. 41, 
lines 1-10) 



For example: the card issuer's name; the minimum and maximum number of digits permitted in the 
credit card issuer's credit card nimibers (called a "primary accx)unt number" or "PAN"); the low end and the high 
end of the credit card number range for this credit card issuer; which types of transactions the card issuer permits; 
etc. (col. 40, lines 13-50) 

^ For example: the bank's merchant identifier; the terminal ID number assigned to the merchant by the 
bank; the name identifying the bank's host computer; the reference number to be used as part of the next 
transaction; etc. (coL 39, lines 20 to col. 40, line 12) 

For example: the Primary Host Address (telephone number or IP address, etc.); the Secondary Host 
Address (telephone number or IP address, etc.) to be used as a backup; a timeout value - how quickly the 
merchant's terminal should receive a response from the bank's host computer; etc. (col. 40, lines 50-67) 
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The passage cited by the Examiner does not read upon the third element of claim 24. The 
passage simply describes a computer program that is built into the merchant's computer system 
130 and that permits the merchant to adjust configuration information values stored within the 
system 130. This passage does not speak of defming any "task definition", as the third element 
of claim 24 requires. The passage does not speak of including in such a task definition a "list of 
... computers" which are to be analyzed or audited, as this third claim element also requires. 
This passage does not speak of including in such a task definition any "list of ... analyzers" (or 
any other computer programs) as this third element further requires, particularly not an analyzer 
whose "executable program steps" must be able to "compute ... a report" form the "configuration 
information gathered from a single computer, a report identifying at least one issue relating to 
the computer" as claim element 2 requires. This passage does not teach computing anything 
from the configuration information found on the merchant's computer system 130 - it only 
teaches assisting the merchant in altering such configuration information, and it does not teach 
computing reports from such information foUowmg some type of analysis. The only executable 
program steps mentioned in this passage is the "configuration setup fimction" whose purpose is 
not to test configuration information nor to compute anything from configuration mformation but 
simply to permit a human to adjust configuration information. This claim language clearly does 
not read upon this passage. 

The Examiner fiirther indicates that this third element of claim 24 reads upon the 
following passage taken from the Weber patent: 

Web Servers can process many transactions at a time, so payment requests 
can often occur simultaneously. Thus, the vPOS Software must have support for 
multi-tasking and provide support for muhiple threads to be active at the same 
time in the same system as well as the same process. This requirement is 
relatively straight forward. However, the autiiorizing banks require that all 
transaction requests include a Terminal ID (TID), and, for many banks, no single 
TID may be active in any two transaction requests that overlap in time. Thus, the 
vPOS requires dynamic allocation of TIDs to requesting threads, (col. 63, lines 
14-24) 
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This passage explains that bank host computers conventionally assign one terminal ED to 
each merchant and do not permit two transactions to take place from the same merchant at the 
same time. Such an arrangement would not permit several Internet payments to be approved 
simultaneously. The answer proposed here is that the merchant's computer system 130 can be 
given a set of several terminal IDs, and then, through the use of conventional "multithreading" or 
multi-tasking techniques, it can process simultaneously as many payment transactions as the 
computer system 130 has terminal IDs assigned to it by the bank. 

The third element of claim 24 does not read upon this passage. There is nothing in this 
passage that speaks of defining a task definition by listing analyzers that are to be exercised and 
by listing the computers on whose configxwation data those analyzers are to perform 
computations. This claim language clearly does not read upon this passage. 

The Examiner finally indicates that this third element of claim 24 also reads upon the 
following passage taken from the Weber patent: 

vPOS Multi-Merchant Processing 

Multiple merchant processing refers to the ability of a plurality of 
merchants to process their individual vPOS transactions securely on a single 
computer. The architecture relies on each payment page obtaining the merchant 
name in a hidden field on the payment page. The vPOS engine receives the 
merchant name with a particular transaction and synchronizes the processing 
utilizing a Set Merchant method. This command causes the vPOS API to look up 
a unique registry tree based on the merchant name. This process causes the vPOS 
engine to engage the appropriate configuration to process the transaction at hand 
utilizing a Registry Tree. A registry tree contains Card Defmition Tables (CDT)s, 
Acquirer Definition Tables (ADT)s, Merchant Definition Tables (MDT)s, 
Protocol Configuration Tables (PCT)s, etc. The CDTs point to specific ADTs 
since each supported card can be supplied by a distinct acquirer. This is one form 
of split connection. Each of the ADTs in turn point to PCTs, and some acquirers 
can support multiple parallel gateways. A merchant's name refers to a unique 
database in the database management system which contains for example, TIDs. 

So, for example, to fiilly qualify a particular merchant in a multi-merchant 
system, the Acquirer Definition Table is queried to ascertain the particular 
Gateway (VFITest), then if Bank of America requires verification of network 
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communication information, the particular CardDT is accessed with for example 
VISA. The particular merchant will service VISA transactions utilizing a 
particular acquirer. The particular piece of merchandise will also be detailed in a 
data base. Finally, the merchant Configurations will also be stored in the database 
to facilitate E-mail and name lookup, [col. 64, lines 15-45] 

This passage says nothing more than that two or more merchants may share a single 
merchant's computer system 130, and it discusses how such a system keeps the bank payment 
information for the multiple merchants separately stored in separate tables. Since the present 
application does not have any teachings on whether or not multiple users may share a single 
computer, and since this topic does not come up in any claim element, this passage would appear 
to be hrelevant to the present invention. The third element of claim 24, which calls for a task 
definition that includes a list of analyzers that are to process configuration information gathered 
from a list of computers, clearly has not relevance to this passage. This claim language clearly 
does not read upon this passage. 

Accordingly, the third element of claim 24 does not read upon any of the passages cited 
by the Examiner. Neither does the fifth element of claim 3 1 and the sixth element of claim 38. 

iv. The Seventh Element of Claim 24 Does Not Read Upon Weber 

The seventh element of claim 24 reads as follows: 

utilizing any issue identifymg report generated during the processing step 
for audit purposes 

This seventh element of claim 24 does not read upon any type of financial auditing 
activity or financial record management activity. In its preamble, claim 24 says specifically that 
the novel method described m the clahn is "a computerized method for auditing the software or 
hardware configurations of... computers". It is not a method for auditing financial and bank 
records. It is not a method for auditing records of inventory turnover (relating to sale of goods). 
It is not a method of auditing (credit card) payment transactions of a merchant. Consistent with 
this, the "reports identifying at least one issue relating to the computer" (claim 24, element 2) 
which result from computations performed upon "configuration information defining each 
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computer's hardware configixration or software configuration or both" (claim 24, element 2), and 
which the sixth element of claim 24 requires to be utilized "for audit purposes," are clearly not 
fmancial nor inventory (of goods) audit reports. They are reports concerning the hardware and 
software configurations of specific computers. The phrase "utilizing any ... report ... for audit 
purposes" which appears in the sixth element of claim 24 is, accordingly, limited to reports 
usefiil for auditing the hardware and software configurations of computers. This claim language 
cannot be construed to cover the types of fmancial reports of a merchant that a certified public 
accountant would be called in to examine during a financial audit. 

The Examiner indicates that this sixth element of claim 24 reads upon the following 
passage of the Weber patent: 

... The merchant could utilize any other computer attached to the Internet 
utilizing a SSL or SET protocol to query the remote vPOS system and obtain 
capture information, payment administration information, inventory control 
information, audit information and process customer satisfaction information. ... 
(col. 64, Imes 1-7) 

This passage is taken fi-om the middle of a longer passage (col. 63, line 52 to col. 64, line 
1 1) which explains that the merchant's computer system 130 (referred to here by its trademark 
name 'VPOS") does not have to be installed on the premises of the merchant's place of business. 
Instead, the merchant's vPOS computer system 130 may be located "at a central host site where 
merchant vPOS systems for various merchants all resided on a single host with their separate 
access points on the Internet." (col. 63, line 65 to col. 64, line 1). Then, as this passage says: 
"The merchant could ... query the remote vPOS [host] and obtain" [col. 64, lines 1-7] from it 
certain information, all relating to the sales of goods and the receipt of payments, including the 
following: 

1. "Capture" information [col. 64, Ime 4] ~ in the context of a merchant's 
payment computer system, meaning information about requests for the "capture" of 
specific customer credit card payments which requests are sent to the host computer 
system of the merchant's acquiring bank, and whether those requests for "capture" were 
approved or not. (Figure 9 and col. 20, lines 23-39) 
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2. "Inventory control" information [col. 64, line 5] ~ in the context of a 
merchant's payment computer system, meaning records of how many of what types of 
goods have been sold by the merchant's computer system to customers. 

3. "Payment admmistration" information [col. 64, lines 4-5] - in the context of a 
merchant's payments computer system, meaning records for each customer of payments 
made by that customer. 

4. "Audit" information [col. 64, line 6] — in the context of a merchant's payment 
computer system, meaning financial information about payments received and inventory 
transfer information about goods sold, all gathered and maintained specifically for the 
merchant's fmancial auditors to study at a later time. 

5. "... And Process Customer satisfaction" information [col. 64, lines 6-7]. The 
Weber patent does not defme what this information is nor how it might be processed. 

This is all financial information - reports of customer payments received, reports of 
inventory turnover, and reports of payments captured for the merchant by the merchant's 
accepting bank. (Some of this information may also be reports of customer survey information 
gathered incidental to the sale and payment processing processes.) These are not reports 
calculated fi'om hardware and software configuration information of the type that the sixth 
element of claim 24 requires be used for computer hardware and software audit purposes. For 
this reason, the claim language clearly does not read upon the above passage. 

The Examiner fiuther indicates that the seventh element of claim 24 also reads upon the 
following passage also taken fi'om the Weber patent: 

Gateway statistics about transaction requests (by transaction type) and 
transaction results (e.g., success, failed due to host, failed due to authentication, 
etc.) can be determined at any time for a particular time interval by generating a 
report, [col. 124, lines 14-17] 

This passage is taken fi-om a description of the features of the payment gateway computer 
system 140 (Figure IB), the one that the merchant's computer system 130 contacts to obtain 
authorization from the merchant's accepting bank to receive individual payments made by credit 
card (etc.) and that the merchant's computer system 130 later contacts to request capture of the 
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individual payments once the corresponding purchase transaction is completed with the 
customer. 

As was discussed above, this payment gateway computer system 140 includes an Internet 
Transaction Gateway (shown in Figure 21 - see col. 119, lines 13-42) which includes system 
administration software 2195 that, as the above passage indicates, can be adjusted by the 
merchant to generate statistical reports indicating, as a possible example, what percentage of 
customer credit card payment authorization requests were approved and what percentage were 
disapproved during the past 24 hour time interval. 

This is not a report computed from collected configuration information defining the 
hardware or software configuration of a computer. This is a report of financial transactions and 
their success or failure. The claim language clearly does not read upon this passage. 

Accordingly, the seventh element of claim 24 does not read upon the passage cited by the 
Examiner. 

V. The "full automation" Limitation in the First Element of Claim 24 
Does Not Read Upon Desgrousillers et al., and Accordingly the 
First Element of Claim 24 does Not Read Upon The 
Combination of Weber with DesgrousiUiers, et aL 

Returning to the first element of claim 24 (discussed above with respect to the fact that it 
does not read upon the Weber patent): 

in a fiiUy automated manner, collecting from each of a plurality of 
networked computers configuration information defining each computer's 
software configuration or hardware configuration or both; 

It will be recalled that the Examiner indicated this claim language reads upon a passage in the 
Weber patent (this was discussed and refiited above), but the Examiner conceded that the Weber 
patent doesn't explicitly teach "fiiU automation" of collecting configuration information, a 
requirement of this first element of claim 24. Accordingly, the Examiner has based his rejection 
upon the combination of a passage in Weber (discussed above) with a passage in Desgrousillers 
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et al which is set forth here (three sentences are set forth here - the third sentence presented (col. 
13, lines 60-62) is the passage pointed out by the Examiner as illustrating "fixll automation"): 

... [T]he test results in storage device 29 can be manually analyzed by the 
user, by providing a printout of the contents of each command and response 
buffer. In fact, in the preferred embodiment, the SCF response format and 
attribute values must be manually reviewed. The SPI test results, on the other 
hand, are all automatically analyzed and the resuh is preferably printed out with 
comments. ... (col. 16, lines 56-62) 

The problem with the Examiner's position is that the first element of claim 24 
specifically calls for "collecting" "configuration information" from "a plurality of networked 
computers" in "a fully automated manner." Directly contrary to all of this, the passage above 
does not mention any "collecting" activity (the "test data" is all conveniently present in a single 
storage device 29 shown in Figure 8); and the passage above also does not mention hardware or 
software configuration information (instead it mentions test results resulting from tests of an 
unwritten program's requirements carried out by a "test SCF imit 25" shown in Figure 8). In 
addition, the process of analysis and report generation described is only partly automated - it is 
partly done manually (as the fiiU passage quoted above clearly indicates). Add to this the fact 
that the Desgrousilliers, et al patent's teachings are not at all relevant either to the present 
claims or to the Weber patent (as was explained above), and it can be seen that the claim 
language clearly does not read upon the final sentence in the passage presented above. 
Accordingly, the first element of claim 24 does not read upon this Desgrousilliers, et al passage 
either alone or in combination with one of the Weber passages. Likewise, the corresponding 
first, second, and third elements of claim 3 1 and the corresponding first, third, and fourth 
elements of claim 38 do not read upon this passage. 

vi. The Second Element of Claim 24 Does Not Read Upon The 
Combination of Weber with Desgrousilliers, et al 

The Examiner conceded that the italicized language appearing below in the second 
element of claim 24 (discussed above with respect to the fact that this claim language does not 
read upon the Weber patent): 
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providing a plurality of analyzers based upon expert knowledge, each 
analyzer comprising the executable program steps needed to compute, from 
selected configuration information gathered from a single computer, a report 
identifying at least one issue relating to the computer; 

was not taught by the three Weber patent passage (discussed above) that the Examiner has cited 
against this claim element. 

Accordingly, the Examiner cited the three Weber patent passages (summarized below), in 
combination with the passage below which is taken from the Desgrotisilliers, et al patent (the 
examiner did not cite the first two sentences presented below - they are included here for 
clarity): 

A knowledgebase design tool ... permits a subsystem developer to reliably 
design a new subsystem control facility using a graphical interface with a 
knowledgebase. ... In this design tool, the subsystem designer is able to call up 
and examine in an orderly manner all of the specific commands and objects to be 
incorporated into the specific proposed subsystem set of requirements, from a 
generic set of permitted commands and objects. In addition, the subsystem 
designer is able to select appropriate error messages, and help and error texts, for 
display purposes. By mdividual selection using the interface keys and guided by 
the interface prompts, the subsystem designer can construct the proposed set of 
requirements. Improper selections by the developer are noted on the screen of the 
graphics interface, thereby enabling the developer to correct syntactical errors and 
rules errors throughout the design process. Once the developer has completed the 
initial set of requirements, the loiowledgebase system then generates an 
appropriate external specification in text form which can be reviewed for 
compliance with the system rules and standards by the quality assurance and 
progranraiatic interface experts. In addition, the knowledgebase system also 
generates a set of help/error text files tailored to the specific conmiands and 
objects of the new set of requirements, a data dictionary language tailored also to 
the set of requirements and a binary table file which contains in binary form the 
command syntax, display format and progranmiatic interface buffer formatting 
information needed to match the new subsystem design. 

SUMMARY OF THE INVENTION 

The invention comprises a method and system incorporated into the above 
described developmental tool for providing automatic test generation after the 
developer has completed the set of requirements, which permits comprehensive 
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testing of both positive and negative performance of the new set of requirements, 
and which permits a new proposed subsystem control facility to be tested 
thoroughly and the testing results analyzed prior to implementation in code form. 
The analyzed test results include traceability to the requirements as expressed in 
the developmental tool knowledgebase. 

From a process standpoint, the invention comprises a method of preparing 
a suite of test scripts for testing a proposed subsystem control facility set of 
requirements in a distributed systems network prior to coding the proposed 
subsystem control facility, .... [col. 3, lines 18-56] 

The Examiner cited this passage in combination with three passages taken from the Weber patent 
(discussed fully above and briefly below) to demonstrate the presence in the prior art of 
analyzers comprising "executable program steps" that were "based on expert knowledge" and 
that could "compute, from selected configuration information gathered from a single computer, a 
report identifying at least one issue relating to the computer". 

With all due respect, this passage from the Desgrousilliers, et al patent teaches no such 
thing, alone or in combination with Weber. The Desgrousilliers et al. patent's teachings are 
directed to assisting a programmer who has yet to write a program m first defining the 
requirements of that proposed program and then in exercising those program requirements 
against test data to see if the requirements are acceptable. This is a progranmier's tool for use in 
a software development laboratory, not a support engineer's tool that can collect configuration 
information from computers operating in the field, and then analyze that information. 

What the Desgrousilliers et al. patent lacks in the above passage, as well as elsewhere, is 
any teachings conceming: "collecting" any information at all; collecting "in a fiiUy automated 
manner;" collecting "from each of a plurality of networked computers;" collecting information 
that can be characterized as "configuration information;" and collecting configuration 
information "defining" any "computer's software configuration or hardware configuration or 
both." In other words, the teachings of the Desgrousilliers, et al. patent are so far removed from 
the present invention that they are entirely irrelevant to the second element of claim 24. 
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Likewise, the combination of this passage taken from the Desgrousilliers, et al patent 
with the three passage of the Weber patent which the Examiner has cited is no more 
enlightening, and the second element of claim 24 still does not read upon such a combination. 

The Examiner furst cited the Weber patent's Abstract, which speaks of a merchant's 
computer system sending requests to approve payments to a "test" central bank computer that 
takes the place of a real central bank computer for testing purposes. Weber's abstract speaks 
about testing an actually operating computer system, not about laboratory testing of the 
requirements of a program not yet written, the topic addressed in the Desgrousilliers, et al 
patent. 

The Examiner next cited a passage in the Weber patent (col. 63, lines 54-63) which 
summarily described how a customer's computer system 120 entered into a secure dialog or 
handshake session (or linkage) 150 with a merchant's computer system 130 which in turn 
entered into a separate secure dialog or handshake session (or linkage) 170 with a payment 
gateway computer system 140 for the purpose of consummating a purchase based upon usage of 
a credit card, with bank approval. Again, this Weber passage has nothing whatsoever to do with 
software development and requirements testing, as taught by the Desgrousilliers et al. patent. 

And finally, the Examiner cited a passage in the Weber patent (col. 137, line 29-63) that 
is taken from a section of the Weber patent that discusses certificate processing. The cited 
passage relates to encryption methods for data managed by a data manager and, in particular, 
discusses a "wallet" feature that "contains personal information." This, again, has nothing to do 
with the teachings of the Desgrousilliers, et al. patent relating to program requirements testing. 

The second element of claim 24 clearly does not read upon any of these passages of the 
Weber patent taken either alone (as discussed above) or in combination with the above passage 
from the Desgrousilliers, et al. patent. 
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The Examiner further indicates that the second element of claim 24 also reads upon the 
three passages from the Weber patent (just summarized) taken in combination with the following 
passage taken from the Desgrousilliers, et al. patent: 

Knowledgebase file storage devices 13 contain a global set of testing 
conditions pertinent to at least the subsystem type or types to which the 
subsystem control facility under development is pertinent. This knowledgebase is 
attached hereto in microfiche form as Appendix D, which is hereby incorporated 
by reference. In general, the testing conditions embody a test generation strategy 
in which the common and minimal set of required techniques is generated. This 
set includes input validation and syntax checking, configuration, including 
boundary-value analysis and equivalence partitionmg (i.e., identifying classes of 
inputs over which behavior is similar), state transitions, transactions, path, static 
testing by consistency verification of the requirement statements, dynamic testing 
of the binary table, version control, and test case— results analysis independence. 
In addition, the test generation strategy includes providing test script input format 
which is valid for use with a test SCF unit and also a coded SCF product module. 
The test generation strategy includes the concept of non-random test generation: 
viz. the same tests should be generated each time the test is run for a given 
subsystem; and generation of values of attributes and the sequence in which the 
SCF commands are generated should also be done in a non-random fashion. In 
addition, a cause and effect component is incorporated into the test strategy, i.e., 
the use of test cases investigating input condition combinations and resulting 
behavior. The actual testing knowledgebase includes a number of files which 
define all general classes, objects and properties, a utility and general rule library, 
and a plurality of test sets which generate specific tests, such as state/node tests 
(Abort, Start, Stop commands), display tests (Info, Status commands), 
miscellaneous tests (Boot, Load commands), attribute tests (Add, Alter, Trace 
commands), negative attribute tests, and other negative tests (all commands, 
specific, Path). The SPI tests generate negative SPI header and specific token 
tests, and positive combinations of specific tokens described below, [col. 5, line 
59 to col. 6, line 28] 

This passage is taken from a description of Figure 1 of the Desgrousilliers, et al patent, a 
figure illustrating a "system for generating a suite of test scripts" for later use in testing out the 
requirements for a program "prior to preparing actual software code (col. 5, lines 27-31) 
This particular passage explains that a global set of "testing conditions" pertinent to a network 
management application program (called a "subsystem control facility" or "SCF" in this 
passage) is available in a storage device 13 to guide a HyperCard program (Illustrated in Figures 
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2-14) in walking the programmer through the process of producing test scripts which, in Figure 
8, is later to be used in testing out the programmer's requirements for that same program. 

There is no mention in this passage of providing analyzers containing executable 
program steps that can compute, from a computer's configuration information, a report of any 
kind. The claim language clearly does not read upon this passage when considered by itself 

When this passage is viewed in combination with the Weber patent Abstract, which 
addresses the topic of how to test an operating merchant's computer system by having it 
communicate with a dummy bank gateway computer system, this combination of the Weber 
patent's teachings relating to the testing of an operating computer with the Desgrousilliers, et al. 
patent's teachings relating to the testing of requirements for a program not yet written is not one 
that makes any sense and is also not one that has anything to do with gathering hardware and 
software configuration information from rurming computers and providing analyzers for such 
information, as element two of claim 24 requires. The claim language clearly does not read upon 
this combination of references. 

When this passage is viewed in combination with column 63, lines 54-63 of the Weber 
patent, the same resuh follows. Lines 54-63 describe how a customer's computer system 120 
enters into a secure dialog or handshake session (or linkage) 150 with a merchant's computer 
system 130 which in turn enters into a separate secure dialog or handshake session (or linkage) 
170 with a payment gateway computer system 140 for the purpose of consummating a purchase 
based upon usage of a credit card, with bank approval. The Weber patent's teachings concerning 
the payment handshake sessions (or linkages) 150 and 170 have nothing whatsoever to do with 
preparing test scripts for software development and requirements testing, as taught by the above 
passage in the Desgrousilliers et al. patent. This combination of references makes no sense at 
all. 

And finally, when this passage is viewed in combination with column 137, lines 26-63 of 
the Weber patent, a passage taken from the Weber patent's discussion of certificate processing. 
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the language of the second element of claim 24 cannot be read upon this combination either. 
The cited passage in Weber discusses a "wallet" feature that "contains personal information." 
This, again, has nothing whatsoever to do with the software requirements testing teachings of the 
Desgrousilliers, et al. patent. 

The claim language clearly does not read upon any of these passages of the Weber patent 
either taken alone (as discussed above) or when taken in combination with the above passage 
from the Desgrousilliers, et al patent. 

The Examiner finally indicates that the second element of claim 24 also reads upon the 
three passages from the Weber patent (just discussed) taken in combmation with the following 
passage taken from the Desgrousilliers, et al patent: 

With reference to the attached analyzed resuhs sample, this sample 
illustrates the analysis of the INFO command using a line object. The contents of 
the command buffer are first set forth followed by the contents of the 
corresponding response buffer. Below these contents, is the analysis summary of 
the header command-response results analysis. As can be seen, there are no errors 
indicated and one warning: viz. the response MAXRESP is not the same as in the 
command buffer. Next follows the summary analysis of the SPI command- 
response results analysis, which indicates the conmiand-response processing is 
valid. Next follows the analysis summary of the COM command-response results 
analysis, which indicates no warnings, and one error. This error is identified as 
missing the ZCOM-TBCN-REQD token. The proper return code (RETCODE) is 
also indicated. There follows a second set of analyzed resuh for the same 
command which illustrates different errors and warnings, the manner in which the 
errors are identified and the reasonmg why the identified item is an error, as well 
as the appropriate correction, [col. 16, Imes 46-65] 

This passage is a brief simmiary description of a report. The actual fiiU text of this same 
report is presented in columns 19 to 28 of the Desgrousilliers, et al patent. 

Here is how this report is generated: With reference to Figure 8, it will be recalled that 
the Desgrousilliers, et al patent teaches that prior to the writing (or coding) of a new network 
management application program, a progranmier prepares a detailed statement of that program's 
requirements (subroutine calls and returns, etc.) and presents the requirements assembled into a 
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subsystem binary table 21 (see Figure 8, and see also col. 10, lines 52-58 and col. 10, lines 65 to 
col. 1 1, line 3). The programmer also prepares test data for these requirements and presents 
them assembled into test scripts 22. The progranmier then has a test unit 25 use the test data 
contained in the test scripts 22 to test or exercise the requirements as presented m the binary 
table 21. The test unit 25 then generates the requirements test results which are presented in a 
detailed test resuhs files 29 that the programmer may then read and study directly (col. 13, lines 
55 to 58). In the case of some of the more standardized test scripts representing standardized 
network management subroutine calls that are made by many network management applications, 
and not in the case of highly specialized subroutine calls unique to the new program under 
development, the programmer may call upon an inference engine 16 which has been 
preprogrammed in the artificial intelligence manner to analyze some the test results files 29 and 
to generate the report (col. 13, lines 60-63) a sample of which appears in columns 19 to 28 of the 
patent and which report is summarized by the above passage cited by the Examiner. In 
summary, then, the above passage describes a report that is generated by an artificial intelligence 
inference engine programmed to read through program analysis requirements test results and to 
condense those test results down into a more readable format for presentation. 

The second element of claim 24 does not read upon this passage. The second element 
calls for the analysis of "configuration information" (not test results) "gathered fi'om a single 
computer" (there is no mention at all of collecting information fi-om single computers in the 
Desgrousilliers, et al. patent) identifying at least one issue "relating to the computer" (not 
relating to some yet-to-be-written program's requirements). The claim language clearly does not 
read upon this passage. 

When this passage is combined with the Weber patent's abstract, the abstract's teachings 
concerning cormecting a merchant's computer system to a test computer, rather than the 
computer of an actual bank, still includes no teachings about collecting and analyzing 
configuration information from individual computers. The claim language does not read upon 
this combination of references. 
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When this passage is viewed in combination with column 63, lines 54-63 in the Weber 
patent, the same result follows. Lines 54-63 describe how a customer's computer system 120 
enters into a secure dialog or handshake session (or linkage) 150 with a merchant's computer 
system 130 which in turn enters into a separate secure dialog or handshake 170 with a payment 
gateway computer system 140 for the purpose of consummating a purchase based upon usage of 
a credit card, with bank approval. Again, the Weber patent's teachings concerning payment 
handshake sessions (or linkages) 150 and 170 have nothing whatsoever to do with preparing test 
scripts for software requirements testing and then analyzing the requirements test results, as is 
taught by the above passage in the Desgrousilliers et al. patent. This combination of references 
makes no sense at all. 

And finally, when this passage is viewed in combination with Weber patent passage (col. 
137, line 29-63) that is taken from a section of the Weber patent which discusses certificate 
processing, the language of the second element of claim 24 cannot be read upon this combination 
either. The cited passage m Weber relates to methods for data managed by a data manager and, 
in particular, it discusses a "wallet" feature that "contains personal information." This, again, 
has absolutely nothing whatsoever to do with the software design and testing teachings of the 
Desgrousilliers, et al. patent relative to the program's requirements. 

The claim language clearly does not read upon any of these passages of the Weber patent 
either taken alone (as discussed above) or when taken in combination with the above passage 
from the Desgrousilliers, et al patent. The same may be said of the corresponding fourth 
element of claim 31 and the corresponding fifth element of claim 38. 

vii. The Third Element of Claim 24 Does Not Read Upon The 
Combination of Weber with Desgrousilliers, et al 

The third element of claim 24 reads as follows: 

defining at least one task definition comprising a list of one or more of 
said computers and a list of one or more of said analyzers; 
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The Examiner maintains that this third element of claim 24 reads upon three different 
passages in the Weber patent (discussed above) when combined with the following passage 
taken from the Desgrousilliers, et al patent: 

... [T]he user specifies by means of... screens those types of test results for 
which analysis is desired. ... Once the user specifies the test results to be 
analyzed, the system 10 uses the knowledge bases ... and the contents of the test 
resuhs files to perform the analysis. 

The areas of analysis are as follows. All SPI requirements are verified for 
a subsystem's conformance. The main ones include: 

Header items and data for both command and response buffers, 
including lengths, SSID, versions; Cross-verify command 
to response buffer header items and data; 
RETCODE, test generator positive or negative test specific; 
DataLists-EndLists response records, including RETCODE, object 
type, name, state, cross-check MAXRESP token, Z- 
(subsystem specific token for INFO and STATUS 
commands); 

ErrLists-EndLists response records, including RETCODE, 

RETCODE and error, error and SSID, object type or name; 
Allow and response type processing with validation; 
Additionally, token code and value verification is made and includes (but 
is not limited to) the following: 

Mis-match between command, object type and object name 
Missing token 
Nonexistent object or token 
Not supported 
Invalid format 

Unsupported format (for example; wildcards) 
Duplicate tokens and or values 
Inconsistent (for example; modifiers, attributes) 
Command-node or state behavior: 
Configuration 

Scenario (for example; sequence) 
State transition 

To start the test results analysis, the user clicks the "Result Analysis" 
button from the main Bartender card. The flowchart in FIG. 9 shows the position 
of the results analysis stack in relation to the Bartender tool stack. 

When the "Result Analysis" button is clicked from the main Bartender 
card, the card shown in FIG. 10 appears. This screen shows the name of the 
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subsystem where the test results, the subsystem version, and other pertinent 
information are analyzed. 

Click the "SCF Test Results" button to move to the SCF test results card 
for analysis of SCF test results. 

Click the "SPI Test Resuhs" button to move to the SPI test resuhs card for 
analysis of SPI test resuhs. 

Types of Test Results 

ThQ types of test resuhs that a user can analyze are: 
SCF test results 

SCF test results for a specific command 

SCF test results for a specific object type 

SCF test resuhs for a specific conmiand-object type pair 

User test results for a specific command-object type pair 

SPI test results 

For the first four SCF test results m the list, a user can specify the analysis 

of: 

a) positive test results 

b) negative test results 

c) both types of test resuhs 

Once the test results to be analyzed have been specified, the tool uses the 
information about the subsystem to analyze the results. 

[col. 13, line 64 to col. 14, line 67 - note that the first (introductory) 
paragraph above was included here by applicants for completeness and clarity, 
but this first paragraph was not actually cited by the Examiner.] 

This passage teaches that an inference engine 16 (Figure 1), guided by artificial 
intelligence data constructs, can be called upon by a programmer to analyze some of the test 
resuhs 29 generated by a test unit 25 (Figure 8) after the test unit 25 has finished testmg the 
requirements (represented by the binary table 21) for a computer program that the programmer 
has not yet written, testing these requu"ements against test data (represented by the test scripts 14 
and 22). This passage teaches fiuther that the computer programmer can "specify the test results 
to be analyzed." 

In contrast to this, the third element of claim 24 calls for 'task definitions" that list the 
analyzers which are to be called upon to perform analysis. The claun thus permits one to select 
which types of analysis are to be performed. Contrary to this, in the above passage, the 
programmer is not permitted to select which analysis is to be performed. Instead, the above 
passage permhs the progranuner to specify which *test results" are to be analyzed. The third 



-55- 



Atty. Dkt.No, 10015199-1 
element of claim 24 also calls for the task definitions to list the computers whose hardware and 
software configuration information is to be subjected to analysis. Contrary to this, the above 
passage calls for test results to be listed, and these test results are not configuration information 
and are not computed fi-om configuration information. These test results come fi^om testing the 
requirements of programs not yet written. Because this passage does not teach listing or 
selecting analyzers and also does not teach listing or selecting computers whose configuration 
information is to be analyzed by the listed or selected analyzers, the claim language clearly does 
not read upon this passage. 

Considering this passage in combination with column 39, lines 13-19 of the Weber 
patent, the Weber passage explains that a merchant can alter information stored on the 
merchant's computer such as information specific to each credit card issuer, mformation specific 
to the merchant's acquiring bank, and also the merchant's name. The above passage taken fi-om 
the Desgrousilliers, et al patent teaches that a programmer testing the requirements for a yet-to- 
be-written program may, following testing of the requirements, select which test results data to 
subject to a fiiU analysis. Clearly, these teachings of Weber and Desgrousilliers, et al are 
completely unrelated and are not combinable in any meaningfiil sense to serve as the basis for 
and obvious-type rejection. 

Considering this passage in combination with column 63, lines 14-24 of the Weber 
patent, a passage that discusses how a single merchant's computer system may be supplied with 
muhiple bank-supplied terminal identifiers so that the merchant's computer can process several 
payment approval or capture transactions simultaneously, again these teachings of Weber 
relating to banking and those of Desgrousilliers, et al. presented in the above passage relating to 
software requirements testing are completely imrelated and are not combinable in any 
meaningfiil sense to serve as the basis for an obvious-type rejection. And the same may be said 
when this passage taken from Desgrousilliers, et al is considered in combination with column 
64, lines 15-45 of the Weber patent that discusses how several merchants may share a single 
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merchant's computer system 130, a topic that is entirely imrelated to Desgrousillier's teachings 
concerning software requirements testing. 

The language of claim 24 's third element clearly does not read upon the combination of 
the above passage taken from the Desgrousilliers, et al patent with any of the three passages 
taken from the Weber patent that the Examiner has cited. The same may be said of the 
corresponding fifth element of claim 3 1 and of the corresponding sixth element of claim 38. 

viii. The Fourth Element of Claim 24 Does Not Read Upon 
Desgrousilliers, et aL 

The Examiner indicates that the fourth element of claim 24: 

in a fiiUy automated fashion, and guided by one or more of said task 
definitions — 

reads upon the following passage taken from the Desgrousilliers, et al patent: 

The SPI test results, on the other hand, are all automatically analyzed and 
the result is preferably printed out with comments, [col. 13, lines 60-62] 

This passage speaks of analyzing automatically some of the "test results" generated by 
the process of testing the software requirements specifications for a yet-to-be-written computer 
program against test data, as has been explained above. This passage says this analysis is 
automatic, and other parts of this patent explain that an inference engine 16 (shown in Figure 1) 
performs this analysis, presumably using artificial intelligence strategies. (The automatically- 
generated report appears in columns 19 to 28.) 

Entirely contrary to this, element four of claun 24 speaks of being guided in a fiilly 
automated fashion by task definitions which claim element three specifies contain lists of 
computers whose hardware and soflAvare configuration information is to be analyzed and which 
claim element three also specifies contain lists of the analyzers whose "executable program 
steps" are to process that configuration information - see claim element two. Clearly, the 
automated testing of hardware and software configuration information taken from a selected list 
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of computers by "executable program steps" contained in a selected list of analyzers is not the 
same as the automated testing of selected test results resulting from program requirements 
testing carried out before a computer program is written. 

The Examiner further indicates that this claim language reads upon column 14, lines 5-67 
of the Desgrousilliers, et al patent. This passage, and the introductory paragraph preceding this 
passage (col. 13, line 64 to col. 14, line 5), were just discussed above, and it was shown that this 
passage teaches that a programmer, who has just tested out the requirements for a computer 
program not yet written, may take the data files resuhing from that testing of requirements and 
automatically analyze selected ones of the test results using an inference engine. 

Essentially the same rationale applies to this passage as applied to the passage just 
discussed above. Briefly stated, element four of claim 24 speaks of being guided in a fiilly 
automated fashion by task definitions which element three specifies contain lists of computers 
whose hardware and software configuration information is to be analyzed and which claim 
element three also specifies contain lists of the analyzers whose "executable program steps" are 
to process that configuration information - see claim element two. Clearly, the automated 
testing of hardware and software configmation information taken from a selected list of 
computers by "executable program steps" contained in a selected list of analyzers is not the same 
as the automated testing of selected test results resuhing from program requirements testing 
carried out before a computer program is written. 

The fourth element of claim 24 clearly does not read upon either of these passages taken 
from the Desgrousilliers, et al patent. Neither does it read upon the corresponding language 
found in the first line of the sixth element of claim 3 1 nor upon the corresponding language 
found in the second and third lines of the seventh element of claim 38. 

ix. The Fifth Element of Claim 24 Does Not Read Upon 
Desgrousilliers, et aL 

The Examiner indicates that the fifth element of claim 24: 
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harnessing each of the task definition's listed analyzers to configuration 
information gathered from each of the task definition's listed computers; 

reads upon Figure 9 of the Desgrousilliers, et al patent. 

With reference to Figure 9 of the Desgrousilliers, et al patent, this figure shows the 
outline structure of a HyperCard stack. "HyperCards" are viewable card images arranged into 
vutual "stacks" of cards each of which can contain one or more mouse-clickable, button-style 
Hypertext linkages to other cards in the same stack that enable one to jump quickly from one 
HyperCard card image to another and back again. Each HyperCard may also display 
information in scrollable windows, etc., and may also have associated with itself interpretable 
program code. 

Figure 9 simply illustrates that a HyperCard card image (not shown in the patent) named 
"Bartender Main" is the topmost card in a "stack 15" (Figure 1) of such cards. Figure 9 also 
indicates that this topmost card, 'Bartender Main," has on its viewable card surface seven 
clickable buttons (not shown) that enable a computer programmer viewing this topmost card to 
navigate (with a click of the mouse button) to any one of seven subsidiary HyperCard images 
within the same stack. The seven subsidiary cards are: "Subsystem Information," "SCF PM 
Generator," "SCF Help and Error," "Generator Table," "SCF ES Generator," "Test Generator," 
and "Results Analysis. 

Of these seven subsidiary card images, only two are shown and discussed to any extent in 
the patent. The first is the "Test Generator" HyperCard card image (shown in Figure 3), a 
HyperCard card image that can guide a programmer through the process of developing test 
scripts that can later be used to test the requirements specifications of a new, not-yet-written 
network management computer program which the programmer wishes to write. The second is a 
"Results Analysis" HyperCard card image (shown in Figure 10), a HyperCard card image that 
becomes useful only after requirements testing has been completed. This card guides the same 
progranmier through the process of analyzing the files of test results 29 (Figures 1 and 8) that 
arise after requirements testing has been completed. 
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The teachings of Figure 9, cited by the Examiner, and of the related Figures 3 and 10 may 
be briefly summarized as follows: A programmer wishing to test out the requirements of a 
"network management application" computer program may use a HyperCard stack to assist the 
programmer in generating requirements test data by clicking down from the "Bartender Main" 
card to the "Test Generator" card shown in Figure 3. After requirements testing is done, the 
programmer may use the same HyperCard stack again to assist the programmer in analyzing the 
results of testing by clicking down from the "Bartender Main" card to the "Results Analysis" 
card shown in Figure 10. 

The Examiner maintains that the language of the fifth element of claim 24 reads upon 
Figure 9. With all due respect, this is simply not true. The fifth claim element calls for the 
analyzers listed in a task definition, including their executable program steps, to be harnessed to 
configuration information gathered from each of the computers also listed in the task definition. 
The idea here is that the executable program steps will compute from the configuration 
information reports of any issues that need to be drawn to management's attention. Nothing at 
all similar to this appears in Figure 9 of the Desgrousilliers, et al patent. Figure 9 contains no 
reference to a task defmition, particularly not to one that lists computers and that also lists 
analyzers. Figure 9 does not teach harnessing listed analyzers to configuration information 
gathered from the listed computers. 

Accordingly, the fifth element of claim 9 clearly does not read upon Figure 9 of the 
Desgrousilliers, et al patent. This, by itself, is an indication that claim 24 is clearly allowable. 
The same may be said of the corresponding lines 2-3 of the sixth element of claim 3 1 and of the 
corresponding lines 1-4 of the seventh element of claim 38. 

X. The Sixth Element of Claim 24 Does Not Read Upon 
Desgrousilliers, et aL 

The Examiner indicates that the sixth element of claim 24: 

harnessing each of the task definition's listed analyzers to configuration 
information gathered from each of the task definition's listed computers; 
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reads upon Figures 3 and 10 of the Desgrousilliers, et al patent. 

Figures 3 and 10 of the Desgrousilliers, et al patent were just described above in 
overview. These two figures show the topmost card in two HyperCard stacks. Briefly 
summarized, "HyperCards" are virtually stackable card images which may contain one or more 
clickable, button-style linkages that enable one to jump from these two topmost card images to 
other card images and also into other programs (called as subroutines). Each HyperCard may 
display information, scrollable windows, etc., and each card may also contain program code. 

Figures 3 illustrates a "Test Generator" HyperCard card that can guide a progranmier 
through the process of developing test scripts that may later be used to test the programmer's 
requirements specification for a new, not-yet-written network management computer program. 
Figure 10 illustrates a "Results Analysis" HyperCard card that can guide the same programmer 
through the process of analyzing the files of test results 29 (Figures 1 and 8) that arise following 
program requirements testing. 

To generate or to select test scripts, a programmer clicks one of the two buttons "SCF 
Tests" or "SPI Tests." Later, after requirements testing is completed, to view and evaluate the 
results of testing, a programmer clicks one of the two buttons "SCF Test Resuhs" or "SPI Test 
Results." The difference between these two pairs of buttons will now be explained. 

The term "SCF" appears in the card clickable button labeled "SCF Test" in Figure 3 and 
in the card clickable button labeled "SCF Test Results" in Figure 10. This term "SCF" is an 
abbreviation for "subsystem control facility," the name given to the general class of computer 
programs (also called "network management applications" - see Abstract, lines 1-2) into which 
general class of programs the new, yet-to-be-written program falls - the program for which 
requirements are to be generated and tested against test scripts. A programmer is assumed to be 
writing a new network management application, or "SCF." In the Desgrousilliers, et al patent, 
The term "SCF" is also used to identify the new program's new and unique interfaces to other 
programs and to the user. These new interfaces are specified in the new program's requirements 



-61- 



Atty. Dkt.No. 10015199-1 
specification, and the programmer must be guided through the process of generating test scripts 
for these new and unique interfaces. The programmer initiates this process by clicking upon the 
"SCF Tests" button. And after requirements testing, the programmer clicks the "SCF Tests 
Resuhs" button to be aided in viewing and evaluating the SCF interface requirements test results, 
a manual process that is not automated (col. 13, lines 59-60). 

The term "SPI" appears in the card clickable button label "SPI Test" in Figure 3 and in 
the card clickable button label "SPI Test Results" in Figure 10, "SPI" is an abbreviation for 
"subsystem progranunatic interface" which is a set of standardized program interfaces (or 
subroutine calls or function calls) that are common to and shared by many or all "network 
management applications." Test scripts have akeady been created ahead of time for any "SPI" 
interface a program's requirements include - SPI test scripts do not have to be created by the 
individual programmer. They are simply selected by the progranmier clicking upon the "SCF 
Tests" button. Also, after requirements testing is completed, the programmer will find that the 
inference engine 16 has been pre-programmed to analyze and to generate a detailed report 
sunmiarizing the "SPI" compatibility testmg (col. 13, lines 60-63, and see the sample report 
presented in columns 19-28 of the patent). 

The teachings of these two figures are thus limited to teaching that a programmer wishing 
to test the requirements of a not-yet-written network management application computer program 
may use two HyperCard stacks to assist with this task. The first stack assists the programmer to 
generate SCF (or brand new) interface test scripts and to select SPI (or standard) interface test 
scripts. This first stack's top card is the HyperCard "Test Generator" which contains the 
clickable buttons "SCF Tests" and "SPI Tests" that the progranmier may use to initiate these two 
tasks. The second stack assists the programmer to view the requu*ements test results after 
testing. This second stack's top card is the HyperCard "Results Analysis." This card contains 
the clickable button "SDF Test Resuhs" which aids the programmer m manually browsing 
through the SCF (or brand new) interface requirements test results, and it also contains the 
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button "SPI Test Results" which initiates the fiilly automatic generation of a report on SPI (or 
standardized) interface requirements test results. 

The Examiner maintains that the language of the sixth element of claim 24 reads upon 
Figures 3 and 10. With all due respect, this is simply not true. The sixth element of claim 24 
calls for the analyzers listed in the task definition and previously (see fifth element of claim 24) 
harnessed to hardware or software configuration information collected from computers also 
listed in the task defmition to process the harnessed configuration information imder the 
guidance of each analyzer's executable program steps, thereby (see claim 24 element 2) 
generating reports identifying issues which are then (see claim 24, element 7) utilizable for audit 
purposes. Nothing at all similar to this appears in Figure 3 or in Figure 10 of the Desgrousilliers, 
et al patent. Figures 3 and 10 contain no reference to a task definition listing computers and 
also listmg analyzers or anything in any way similar to this. Figures 3 and 10 make no mention 
of specific computers and clearly do not speak of harnessing listed analyzers to configuration 
information gathered from listed computers. Figures 3 and 10 do not contain any reference to an 
analyzer's "executable program steps" and to "processing" - Figure 3 only makes mention of 
test scripts and data, and Figure 9 only makes mention of test result files - both forms of data, 
not executable program steps. 

Accordingly, the language of the sixth element of claim 24 clearly does not read upon 
Figure 3 or upon Figure 10 of the Desgrousilliers, et al. patent, and on this basis alone claim 24 
is clearly allowable. The same may be said of the corresponding lines 3-5 of the sixth element of 
claim 3 1 and of the corresponding lines 4-7 of the seventh element of claim 38. 

For all of the above reasons, the combination of the Weber and Desgrousilliers, et al. 
patents do not render obvious claims 24, 31, and 38 of the present application. Accordingly, 
allowance of clauns 24, 3 1, and 38 is respectfully requested. 

b. Claim 25 is Patentable Over The Combination of Weber and 

Desgrousilliers, et al Claims 32 and 38 Are Also Patentable for the 
Same Reasons 
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Method dependent claim 25 corresponds to and parallels system dependent claim 32, and 
it also parallels the second element of "means for" system independent claim 38 . Accordingly, 
all the reasons presented below supporting the patentability of claim 24 are equally applicable to 
the claims 3 1 and also to that particular passage of claim 38. (The remaining elements of claim 
38 correspond to and parallel the elements of claim 24, discussed above.) 

i. The First Element of Claim 25 Does Not Read Upon Weber 

The first element of claim 25 reads as follows: 

wherein the collecting step includes placing this configuration information 
into a tracker database fi-om which configuration information is later retrieved 
during the harnessing or processing steps; 

This first element of claim 25 requires the collected configuration information to be 
stored in a tracker database and later retrieved fi'om that database when harnessed to the 
analyzers for computations. 

The Examiner maintains this claim language reads upon the following passage taken 
fi-om the Weber patent: 

The payment gateway provides support for configuring and installing the 
Internet payment capability utilizing existing host point-of-sale technology. The 
payment gateway also provides an intuitive Graphical User Interface (GUI) with 
support built in to acconunodate fiiture payment instruments such as debit cards, 
electronic checks, electronic cash and micropayments. The payment gateway 
implements secure transactions using RSA public-key cryptography and the 
MasterCardA^isa Secure Electronic Transaction (SET) protocol. The gateway also 
provides fiill functionality for merchant payment processing including 
authorization, capture, settlement and reconciliation while providing monitor 
activity with reporting and tracking of transactions sent over the Internet, [col. 15, 
lines 36-49] 

a passage that describes a bank's payment gateway computer - this passage has nothing 
whatever to do with configuration information, and is irrelevant to the first element of claim 25. 

The Examiner also cites Weber, a passage that says: 
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... |T]he merchant Configurations will also be stored in the database to 
facilitate Email and name lookup, [col. 64, lines 44-45] 

This passage is not discussing hardware and software configurations of computers - it is 
discussing information specific to banking transactions and relating to the merchant's identity, 
the credit card issuers, and the merchant's acquiring bank. This type of configuration 
information, which is not computer hardware and software configuration information, is 
irrelevant to the present invention. 

The Examiner fijrther cites the following Weber passage: 

... In Step 5230 a message representing the SET request is inserted into the 
database for tracking purposes, and control proceeds to Step 5240. [col. 142, 
lines 52-54] 

This passage was fiiUy discussed above. Briefly summarized, and as was explained above, a 
"SET request" is a request by a merchant made to the merchant's bank relating to customer 
payment approval and capture and having nothing whatsoever to do with computer hardware or 
software configuration information. Thus, a database for SET request messages is not a tracker 
database containing gathered configuration information relating to computers. This passage is, 
accordingly, also not relevant to the first element of claim 25. 

Accordingly, the first element of claim 25 does not read upon any of these prior art 
passages, and neither does the corresponding first element of claim 32 or the "tracker database 
means" passage within the first element of claun 38. 

ii. The Second Element of Claim 25 Does Not Read Upon 
Desgrousilliers, et aL 

The second element of claim 25 reads as follows: 

wherein the providing analyzers step includes placing these analyzers into 
an analyzer database fi-om which analyzers are later retrieved during the 
harnessing or processing steps; 
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This second element of claim 25 also requires the analyzers, and their executable 
program steps, to be stored in an analyzer database. 

The Examiner maintains this claim language reads upon the following passages taken 
from the Desgrousilliers, et al. patent: 

From an apparatus standpoint, the invention comprises a system for 
preparing a suite of test scripts for testing a proposed subsystem control facility 
set of requirements prior to coding the proposed design, the system including first 
knowledgebase containing the rules governing the operation of a managed 
database network and a library of permitted conmiands and objects, second 
knowledgebase containing test generation information relating to the commands 
and objects specific to the proposed subsystem control facility set of 
requirements, a user interface coupled to the knowledgebase for permitting 
selection of types of tests and specific conmiands and objects to be tested, and test 
script generator coupled to the first and second knowledgebases for generating a 
suite of test scripts from the first and second knowledgebases for use in testing the 
proposed set of requirements prior to coding. The library contained in the first 
knowledgebase includes a global set of object types, object, permitted object 
attributes and permitted object values. The second knowledgebase containing test 
generation information includes a set of conmion and minimal required test 
techniques, including positive tests for testing the ability of the proposed 
subsystem control facility to process valid commands, objects and other data, and 
negative tests for testing the ability of the proposed subsystem control facility to 
process invalid commands, objects and other data. The test script generator 
includes a portion for generating a plurality of test script files and corresponding 
template files, [col. 4, lines 15-41] 

This passage describes, from a "hardware" perspective, the program requirements testing 
system (fully described above). This passage describes two knowledgebase that contain rules, 
the syntax of commands, descriptions of software object types and attributes, and test techniques 
- all data, and none of it executable program steps for computing reports from hardware and 
software computer configuration information. Thus, this passage does not describe a data base 
for "analyzers," as that term is defined in the claims and in the specification. 
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Accordingly, the second element of claim 25 does not read upon this passage of the 
Desgrousilliers, et al patent, and neither does the second element of claim 32 and the "analyzer 
database means" language in the first element of claim 38. 

iii. The Third Element of Claim 25 Does Not Read Upon 
Desgrousilliers 

The third element of claim 25 further requires any issue identifying reports generated to 
be placed into an issues database from which they may be later retrieved: 

wherein the processing step includes storing any issue identifying report 
generated in an issues database from which it may later be retrieved and utilized. 

The term "issues" is defined in the specification to mean "... any matter that may need to 
be investigated by or reported to the management of an enterprise. An analyzer performs tests 
upon configuration data gathered from the nodes of an enterprise by collectors. These tests 
determine if there are any issues that need to be drawn to management's attention." 
(specification, paragraph [0067]) 

The Examiner has cited against this passage the Desgrousilliers et al. patent, and in 
particular. Figure 1, and more specifically items 18 (a mechanism for transferring files "FTP"), 
29 (a file containing the results of requirements testing), 15 (a stack of HyperCards used to guide 
the definition of test data for program requirements testing, as shown in Figure 3, and to guide 
the analysis of program requirements test results, as shown in Figure 10), and 31 (a knowledge 
base that somehow guides the process of reviewing the results of program requirements testing). 

None of this is relevant to the present invention. With reference to both Figures 1 and 8 
of the Desgrousilliers, et al patent, a program's requirements, represented by a subsystem 
binary table 21, is tested by a test unit 25 against test scripts, and the results of this testing are 
placed in the test resuhs file 29 where they may be reviewed with the aid of the HyperCard 
stacks 15. This has nothing whatsoever to do with performing tests upon configuration 
information gathered from computers that are operating normally in the field and reporting issues 
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to management. Figure 1 of the Desgrousilliers et al. patent is simply not relevant to this claim 
language. 

Accordingly, the third element of claim 25 clearly does not read upon this passage. 
Neither does the corresponding third element of claim 32, and neither does the corresponding 
"issues database means" passage in the first element of claim 38. 

c. Claim 26 is Patentable Over The Combination of Weber and 

Desgrousilliers, et aL Claims 33, 39, and 41 Are Also Patentable for 
the Same Reasons 

Method dependent claim 26 corresponds to and parallels system dependent clahn 33 and 
"means for" system dependent claims 39 and 41. Accordingly, all the reasons presented below 
supporting the patentability of claim 24 are equally applicable to the claims 33, 39, and 41. 

26. A method in accordance with claim 25 wherein the processing step 
further includes storing at least some issue identifying reports generated in an 
issues database together with the identity of the computers whose configuration 
information was processed to generate those reports and from which issues 
database both the issue identifying reports and the identity of the computers may 
later be retrieved and utilized. 

This claim says that the issue identifying reports are supplemented with information 
identifying the computer upon which each issue arose, and hence the identity of the computer 
that gave rise to an issue can later be inserted into reports to management along with a report of 
the specific issue. This computer identity mformation is information which the analyzers never 
receive and do not process - the analyzers are very simple programs which are harnessed to 
configuration data and which identify issues without having to concern themselves with the 
identity of the computer from which the configuration mformation was gathered. The harness 
mechanism, or some related mechanism, simply stores the computer identity issue in an issue 
database along with the identity of the computer, which is known to the harness mechanism. See 
Figure 21 of the present application, where the issue XML output 2124 of the analyzers 21 10, 
2112, and 21 14 is supplemented with the identity of the computer before it is placed into the 
issue XML report 2126. This is done by the analyzer loader 2102. See paragraph [0187] of the 
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present application, where this is fiiUy explained in detail. This is a significant feature of the 
present invention which simplifies greatly the task of writing the executable program steps of an 
analyzer, keeping the analyzer programs very short and simple. 

The Examiner rejects this claim for the same reason he rejected claim 25. Applicants 
submit that this rejection is not well founded for the same reasons that were set forth above with 
respect to claim 25. In addition, the Desgrousilliers, et al patent has no teachmg whatsoever 
that an analyzer's executable program steps should identify an issue by processing hardware or 
software configuration information taken from a computer, and that the results of that 
computation should be stored along with the identity of the computer that gave rise to the issue. 
Computer identity is never discussed in the Desgrousilliers, et al patent, which focuses only 
upon analyzing the requirement's specification for a single computer program and not upon 
analyzing configuration information gathered from plural computers. 

The claim language of claim 26 clearly does not read upon Figure 1 of the 
Desgrousilliers, et al patent. Neither does the language of the corresponding claims 33,39, and 
41. 



d. Claim 27 is Patentable Over The Combination of Weber and 

Desgrousilliers, et al Claim 34 Is Also Patentable for the Same 
Reasons 

Method dependent claim 27 corresponds to and parallels system independent claim 34, 
Accordingly, all the reasons presented below supporting the patentability of claim 27 are equally 
applicable to claim 34. 

27. A method in accordance with claim 24 wherein the processing step 
further includes generating, along with at least some issue identifying reports that 
are generated, the identity of the computers whose configuration information was 
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processed to generate those reports such that both the issue identifying reports and 
the identity of the computers may be utilized. 

This claim is essentially the same as claim 26 just discussed, but it leaves out the 
limitation introduced in claims 25 and 26 that the issue identifying reports and the computer's 
names are stored together in an issue database. In this claim, both the issue identifying reports 
and the computer names are generated and may be utilized. The argxmient for patentability is, 
thus, the same as that presented in support of claim 26. The Examiner rejected this claim for the 
same reasons he rejected claims 25 and 26, and applicant's response is the same as what was just 
stated with respect to claim 26. The claim language of claim 27 clearly does not read upon 
Figures 1, 3, or 10 of the Desgrousilliers, et al patent. Neither does the language of the 
corresponding claun 34. 

e. Claim 28 is Patentable Over The Combination of Weber and 

Desgrousilliers, et aL Claims 35 and 40 Are Also Patentable for the 
Same Reasons 

Method independent claim 28 corresponds to and generally parallels system independent 
claim 35 and "means for" system independent claim 40. Accordingly, all the reasons presented 
below supporting the patentability of claim 28 are equally applicable to the claims 35 and 40. 

Claim 28 adds another major feature of the invention to the claims. As is shown in 
Figure 8 of the present application, the issue identifying reports (introduced in claim 24), 
together with the identity of each computer whose configuration information was processed to 
generate those reports (introduced in claim 27)^* are now (claim 28) used as data to guide in the 
processing of audit report templates 204 into one or more audit reports. Claim 28 also requires 
that the task definition, which already lists the analyzers and the computers whose configuration 
information the analyzers are to process, fiirther include a list of the report templates, as is shown 
at 814 in Figure 8. Thus, extremely simple analyzer executable program steps and a harness 
mechanism which applies the analyzers to configuration information and keeps track of fi-om 



Claim 40 does not include this computer identity limitation. 
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which computers that information came are now supplemented with more sophisticated report 
templates that are able to guide the production of intelligible reports identifying in human 
understandable terms which issues arose on what machines. 

The Examiner has broken the language of claim 28 into three parts, which are discussed 
separately here. 

i. The First Element of Claim 28 Does Not Read Upon Desgrousilliers, 
etaL 

The Examiner first maintains that the first element of claim 28, which introduces "report 
templates" as an element of the mvention: 

providing a plurality of audit report templates; 

reads upon col. 4, lines 12-14 of the Desgrousilliers, et al patent. The Examiner cited only a 
single sentence, and it is italicized in the longer passage that is reproduced just below. 
(Applicants have reproduced portions of a preceding sentence to clarify the meaning of the word 
"uses" which appears in the italicized sentence actually cited by the Examiner): 

From a process standpoint, the invention comprises [col. 3, lines 52-53] ... 
using the first and second knowledgebases to generate a suite of test scripts for 
testing the proposed set of requirements prior to coding, [col. 3, line 66 to col, 4, 
line 1] ... The step of using includes the step of generating test scripts and 
corresponding templates for mapping the test scripts into a subsystem, [col. 4, 
lines \2-\A ofXYiQ Desgrousilliers, etal patent] 

This passage in the Desgrousilliers, et al patent is inunediately followed by another passage 
which the Examiner has cited against similar claim language relating to "audit report templates" 
and appearing in the claims 29 and 30. It is thus appropriate to reproduce that passage at this 
point in the discussion. The final sentence of this lengthy passage, the only sentence mentioning 
"templates," is also italicized to make it stand out: 

From an apparatus standpoint, the invention comprises a system for 
preparing a suite of test scripts for testing a proposed subsystem control facility 
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set of requirements prior to coding the proposed design, the system including first 
knowledgebase containing the rules governing the operation of a managed 
database network and a library of permitted commands and objects, second 
knowledgebase containing test generation information relating to the commands 
and objects specific to the proposed subsystem control facility set of 
requirements, a user mterface coupled to the knowledgebase for permitting 
selection of types of tests and specific commands and objects to be tested, and test 
script generator coupled to the first and second knowledgebases for generating a 
suite of test scripts fi"om the first and second knowledgebases for use in testing the 
proposed set of requirements prior to coding. The library contained in the first 
knowledgebase includes a global set of object types, object, permitted object 
attributes and permitted object values. The second knowledgebase containing test 
generation information mcludes a set of common and minimal required test 
techniques, including positive tests for testing the ability of the proposed 
subsystem control facility to process valid commands, objects and other data, and 
negative tests for testing the ability of the proposed subsystem control facility to 
process invalid commands, objects and other data. The test script generator 
includes a portion for generating a plurality of test script files and 
corresponding template files, [col. 4, lines 15-41] 

To determine the meaning of 'template" which appears in the two italicize passages set 
forth above, one must review and study other portions of the Desgrousilliers, et al patent, 

A later passage (col, 9, line 44 to col. 10, line 41) explains that these templates are 
needed to present the test script data in different ways in different testing contexts (col. 10, lines 
40-41). 

... The purpose of the template file is to provide ... : 

Portable test scripts to systems with different addresses, process names, 

configuration requirements . 
Adjustable test scripts for subsystem or platform sensitive data, [col. 9, 

lines 46-51] 

But this special context of using templates to prepare test data for presentation in machine 
understandable form for submission to various automated test regimens on differing platforms is 
far different than the context of using templates to transform issue identification brief reports and 
the names of the computers where those issues arose into meaningfiil, human understandable 
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audit reports. Thus, this passage taken from the claim clearly does not read upon either of the 
two passages quoted above which were cited by the Examiner. 

Accordingly, the first element of claim 28 does not read upon these passages of the 
Desgrousilliers, et al patent, and neither does the corresponding first element of claim 35, 
second element of claim 40, and third element of claim 30. 

ii. The Second Element of Claim 28 Does Not Read Upon 
DesgrousiUiers, et aL 

The Examiner next addresses the second element of claim 28: 

definmg the at least one task definition to further comprise a list of one or 
more audit report templates; [claim 28, second element] 

This says that the task definition, in addition to listing the computers whose configuration 
mformation is to be analyzed and the analyzers that are to perform this analysis, also lists the 
audit report templates which are to be used for report generation. 

The Examiner mamtains that this clahn language reads upon another passage taken from 
the DesgrousiUiers, et al patent. This passage reads as follows: 

... The second knowledgebase containing test generation mformation 
includes a set of common and minimal required test techniques, includmg positive 
tests for testing the ability of the proposed subsystem control facility to process 
valid commands, objects and other data, and negative tests for testing the ability 
of the proposed subsystem control facility to process invalid commands, objects 
and other data. The test script generator includes a portion for generating a 
plurality of test script files and corresponding template files, [col. 4, lines 33-41] 

In this passage, the "proposed subsystem control facility" is the not-yet-written program 
whose requirements are to be tested in an automated fashion against test data. This passage 
describes a "second knowledgebase" (13 in Figure 1) and explains in summary fashion that the 
novel "test generator" being described is guided by this knowledgebase in the generation of "test 
script files and corresponding template files." These template files are used as was just 
explained above to prepare the test data for use in possibly different contexts. Accordingly, a 
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claim which speaks of templates for transforming computer names and issue identification 
reports into human-understandable audit reports does not read upon this use of templates to 
massage test data for presentation in different testing envirormients. 

The second element of claim 28 clearly does not read upon this passage. Neither does the 
corresponding second element of claim 35 nor the corresponding third element of claim 40. 

iii. The Third Element of Claim 28 Does Not Read Upon the Weber 
Patent 

Finally, the Examiner addresses the third element of claim 28: 

following the storing step, and guided by the task definition's listed audit 
report templates and by any issue identifying report generated during the 
processing step, generating one or more audit reports. 

This says that "audit reports" (of the hardware and software configurations of computers — see 
the preamble of independent claim 24) are to be generated "guided by the task definition's listed 
audit report templates and by any issue identifying report generated" during the harnessing of 
analyzer executable code to the configuration data under test. 

The Examiner maintains that this claim language reads upon two passages taken firom the 
Weber patent. The first passage taken fi"om the Weber patent is: 

The merchant could utilize any other computer attached to the Internet 
utilizing a SSL or SET protocol to query the remote vPOS system and obtain 
capture information, payment administration information, inventory control 
information, audit information and process customer satisfaction information, 
(col. 64, lines 1-7) 

This passage, as was explained above, relates to financial auditmg of bank payment 
transaction records, as is clear fi-om the context of this passage, and not audit reports used "for 
auditing the software or hardware configurations of a plurality of computers in one or more 
enterprises" as the claim 24 preamble and other claim elements require. The first element of the 
claim requires the collection of configuration information from computers relating to their 
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hardware and software configurations, for example. The claun language clearly does not read 
upon this passage which relates to bank transaction auditing records. 

The second passage taken fi-om the Weber patent is: 

Gateway statistics about transaction requests (by transaction type) and 
transaction results (e.g., success, failed due to host, failed due to authentication, 
etc.) can be determined at any time for a particular time interval by generating a 
report, [col, 124, lines 14-17] 

The "transaction requests" discussed here are requests by a merchant's computer made to 
the merchant's bank's computer to request authorization to extend credit to a particular customer 
and, later on, to request capture of that payment. These transactions are payment transactions. 
They have nothing whatsoever to do with the hardware and software configxiration of plural 
computers. There is also no mention here of the use of templates for report generation purposes 
in this passage and elsewhere in the Weber patent. Once again, the claim language clearly does 
not read upon this passage of the Weber patent. 

Accordingly, the third element of claim 28 does not read upon either of these passages 
taken from the Weber patent. Neither does the corresponding third element of claim 35, and 
neither does the corresponding foiuth element of claim 40. 



f. Claim 29 is Patentable Over The Combination of Weber and 

Desgrousilliers, et aL Claim 36 Is Also Patentable for the Same 
Reasons. The First Element of Claim 40 Renders Claim 40 Patentable 
For the Same Reasons 

Method dependent claim 29 corresponds to and parallels system dependent claim 36. 
Accordingly, all the reasons presented below supporting the patentability of claim 24 are equally 
applicable to the claim 36. Also, the third element of claims 29 and 36 correspond to the first 
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element of claim 40, and accordingly the discussion presented below relative to the third element 
of claim 29 also supports the patentability of claim 40. 

Claim 29 is quite similar to claim 25, discussed above, in that it defines databases where 
the configuration information, the analyzers, and the issue identifying reports are placed. Claim 
29, in addition, provides a report template database for the audit report templates that were 
introduced in claim 28. 

i. The First, Second, and Fourth Elements of Claim 29 are Patentable 
For the Same Reasons as the First, Second, and Third 
Elements of Claim 25 

The Examiner has rejected claim 29 based upon passages taken fi-om both the Weber and 
Desgrousilliers, et al patents. Of these rejections, those against the claim 29 passages that begin 
"wherein the collecting step ..." (first element of claim 29), 'Svherein the providing analyzers 
step ..." (second element of claim 29), and "wherein the utilizing step ..." (fourth element of 
claim 29) are essentially identical to, and based upon the same cited references, as the 
Examiner's rejections that were applied against the claim 25 passages that begin "wherein the 
collecting step ..." (first element of claim 25), 'Svherein the providing analyzers step ..." (second 
element of claun 25), and "wherein the processing step ..." (third element of claim 25). 
Accordingly, and as to the first, third, and fourth elements of claim 29 which correspond to the 
first, second, and third elements of claim 25 and against which corresponding elements the 
Examiner has cited the same prior art passages,^^ applicants' arguments set forth above in 
support of the patentability of claim 25 are hereby incorporated by reference at this point as 
arguments fiiUy supporting the patentability of claims 29 and 36. For the same reasons that were 
set forth above with respect to claim 25, the claim language of the first, second, and fourth 
elements of claims 29 and 36 clearly does not read upon the references cited against this claim 
language (references listed and fully discussed in the discussion presented above of claim 25). 



Weber patent, col. 15, lines 36-49; col. 64, lines 44-45; and col. 142, lines 52-54 were cited against the 
first elements of claims 25 and 29. Desgrousilliers, et al patent, col. 4, lines 15-41 was cited against the second 
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ii. The Third Element of Claim 29 Does Not Read Upon Weber or 
Desgrousilliers, et al 

There remains the third element of claim 29, reproduced here, which discusses audit 
report templates: 

wherein the providing audit report templates step includes placing these 
templates into a report template database from which they may be later retrieved 
during the audit report generating step; 

The Examiner first maintains that this report template passage reads upon two Weber 
patent passages aheady discussed above (coL 64, lines 1-7 and col. 124, lines 14-17 on pages 81- 
82) with respect to the third element of claim 29 in the same context of the "audit report 
templates" and their use. In this regard, the Examiner says: "The rejection of claim 28 is 
incorporated." Likewise, applicant's response with respect to the third element of claim 29 is 
incorporated by reference at this point, including applicant's discussion of the Weber patent's 
passages col. 64, lines 1-7 and col. 124, lines 14-17 which were presented above. This claim 
language clearly does not read upon these two passages. 

The Examiner next maintains that this report template passage reads upon a 
Desgrousilliers, et al passage set forth here: 

... The second knowledgebase containing test generation information 
includes a set of common and minimal required test techniques, including positive 
tests for testing the ability of the proposed subsystem control facility to process 
valid commands, objects and other data, and negative tests for testing the ability 
of the proposed subsystem control facility to process invalid commands, objects 
and other data. The test script generator includes a portion for generating a 
plurality of test script files and corresponding template files, [col. 4, lines 33-41] 

This passage was discussed fiilly above in Applicants' response with respect to the 
second element of claim 28. For all of the reasons previously stated with respect to the second 
element of claim 28, which required a list of report templates to be included in the task 

elements of claims 25 and 29. DesgrousilUers, et al patent Fig. 1, items 18, 29, 15, and 31 were cited against the 
third element of claim 25 and against the fourth element of claim 29. 
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definition, this claim language, which focuses upon providing a database for the report 
templates, clearly also does not read upon the third element of claim 29. 

Accordingly, the third element of claim 29 does not read upon the two cited passages, 
and neither do the corresponding third element of claim 36 and the corresponding first element 
of claim 40. 

g. Claim 30 is Patentable Over The Combination of Weber and 

Desgrousilliers, et al Claims 37 and 42 Are Also Patentable for the 
Same Reasons 

Claim 30 is a narrower, independent claim that corresponds to and parallels narrower, 
independent system claim 37 and narrower, independent system "means for" claim 42. 
Accordingly, all the reasons presented below supportmg the patentability of claun 30 are equally 
applicable to the claims 37 and 42. 

Claim 30 is a narrower, independent claim that includes many of the same limitations as 
do the claims 24 through 29. In every instance, the Examiner has applied essentially the same 
grounds for rejection to the elements of claim 30 that the Examiner applied to the corresponding 
elements of the claims 24 through 29. Accordingly, since all of these grounds for rejection have 
been fully addressed above as to individual claim elements, they need not be addressed here 
again. Applicant's earlier responses with respect to the elements of the claims 24 to 29 are 
accordingly hereby incorporated by reference and applied in support of the patentability of the 
corresponding elements of claim 30. 

The elements of claim 30 correspond as follows to the elements of previously discussed 
claims 24, 27, 28, and 29: Claim 30's preamble corresponds to that of claim 24; elements one 
and two of claim 30 correspond to elements one and two of both claims 24 and 29; element three 
of claim 30 corresponds to element one of claim 28 and element three of claim 29; element four 
of claim 30 corresponds to element three of claim 24 and element two of claim 28; elements five, 
six, and seven of claim 30 correspond respectively to elements four, five, and six of claim 24; 
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element eight of claim 30 corresponds to claim 27 and to element four of claim 29; and element 
nine of claim 30 corresponds to element three of claim 28. 

For the reasons set forth previously as to claims 24, 27, 28, and 29, the method claim 30 
clearly does not read upon any of the passages in the two patents that were cited against it by the 
Examiner, and neither do the two corresponding system claims 37 and 42. 

h. The Remaining Claims 31-36 and 38-42 Are Patentable For The Reasons 
Set Forth Above With Respect to Claims 24-29 

Claims 31 to 36 are "system" claims that correspond to the "method" claims 24 to 29 
aheady discussed fully above. Accordmgly, all the reasons set forth above with respect to why 
claims 24 to 29 are patentable are equally applicable to the system claims 31 to 36. Applicant 
hereby incorporates by reference all of the argimients set forth above in favor of the patentability 
of the claims 24 to 29 as arguments fully supporting the patentability of the system claims 3 1 to 
36. 

Claims 38 to 41 are also "system" claims but are written using "means for" terminology. 
Claim 38 corresponds to the combination of "method" claims 24 and 25. Claims 39 and 41 both 
correspond to "method" claim 26. Claim 40 corresponds to "method" claim 28, except that its 
first element corresponds to the third element of method claim 29. Accordingly, applicant 
hereby incorporates by reference all of the arguments set forth above in favor of the patentability 
of the claims 24-26 and 28-39 as arguments fully supporting the patentability of the "means for" 
system claims 38 to 41. 

All of the prior art that the Examiner has cited against any of the claims 31-36 and 38-41 
was presented and fully discussed during the discussion presented above of the claims 24 to 29 
(excepting a few prior art passages unique to the higher-numbered claims, which are discussed 
below in the following section). That discussion presented above is hereby incorporated by 
reference as fiilly applicable to the corresponding elements of the claims 31-36 and 38-41. That 
discussion presented above points out, at the end of each discussion of an element of one of the 
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claims 24 to 29, to which element of the claims 31-36 and 38-41 that element discussion is also 
applicable. 

i. Discussion of References Cited Against Various Elements of Claims 31, 37, 
38, and 42 and Not Discussed Previously 

i. The First Element of Claims 31, 37, 38, and 42 Do Not Read Upon 
Weber 

With respect to the independent claims 31, 37, 38, and 42, the Examiner additionally 
cited the following passage taken from the Weber patent: 

Transaction Performance Monitoring and Measurement 

The "hits" performance indicators are available from the Web server. 
Statistics can be generated at any time to highlight the load pattern or to pinpoint 
the time when the server was most active. 

Gateway statistics about transaction requests (by transaction type) and 
transaction results (e.g., success, failed due to host, failed due to authentication, 
etc.) can be determined at any time for a particular time interval by generating a 
report, [col. 124, Imes 9-18] 

This passage was discussed above m the context of the second element of claim 24, 
against which the Examiner cited only the last sentence of this passage. The Examiner cited this 
entire passage against the first element of system claim 31 and against the similarly-worded first 
elements of the system claims 37, 38, and 42. For example, the first element of system claim 31 
reads as follows: 

a plurality of computers each computer having software and hardware 
components configured in a variety of measurable ways; [claim 31, first element] 

Since this first element of system claim 3 1 is a "hardware" element and accordingly does 
not correspond to any particular method element of method claim 24, a separate discussion of 
this grounds for rejection is presented here. 

This claim language calls for the presence of computers that have software and hardware 
elements that are configured. The passage cited by the Examiner does not teach this. Instead, 
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this passage discusses ways in which statistics may be gathered as to the performance of a 
merchant's payment management computer - statistics relating to customer payment 
transactions, not to the hardware and software configuration of individual computers. Thus, the 
claim language does not read upon this passage. 

The Examiner also cites another Weber patent passage against this same claim language: 

A Data Manager provides storage and retrieval of generic data items and 
database records. It is assimied that data fields, index fields or entire data records 
can be marked as encrypted and the encryption process is largely automated. The 
data manager has no specific knowledge of database records appropriate to 
different payment methods. This layer is separated out so as to reduce changes 
required when new payment methods are introduced. However RSA key pairs and 
certificates might be considered as "simple" data types. This component also 
provides an abstraction which supports wallet files on computer disk or contained 
in smart cards. 



The Open Data Base Connectivity (ODBC)/Java Data Base Connectivity 
(JDBC) component provides Data Base Connectivity where formal database 
components are required. An embodiment of the Smart Card Wallet allows wallet 
data to be stored and/or secured by a cryptographic token. 

A preferred embodiment includes a single file or directory of files 
comprising a "wallet" which contains personal information and information about 
muhiple payment methods with the preferred implementation. These payment 
methods (Visa cards, debit cards, smart cards, micro-payments etc. ) also contain 
information such as account mmibers, certificates, key pairs, expiration dates etc. 
The wallet is envisaged to also contain all the receipts and transaction records 
pertaining to every payment made using the wallet. A Cryptographic API 
component provides a standard interface for RSA and related cryptographic 
software or hardware. This support includes encryption, signature, and key 
generation. Choice of key exchange algorithm, synraietric encryption algorithm, 
and signature algorithm should all be configurable. A base class stipulates generic 
behavior, derived classes handle various semantic options (e.g. software based 
cryptography versus hardware based cryptography.) [col. 137, line 26-63] 



This passage was fiilly discussed above in the discussion of the first element of claim 24. 
As was demonstrated in the discussion above, it is not relevant to the present invention. And 
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with respect to the first element of claim 3 1 and comparable language foxmd in claims 37, 38, 
and 42, this passage does not teach providing multiple computers having configured hardware 
and configured software. 

Accordingly, the first element of claim 3 1 clearly does not read upon either of these 
passage. Neither do the corresponding first elements of the claims 37, 38, and 42. 

ii. Claims 38, 40, and 42 Do Not Read Upon Figure lA of the Weber 
Patent 

The Examiner cited as prior art the Figure 1 A of the Weber patent against a variety of 
elements of claims 38, 40, and 42. Figure lA was not cited against any of the other claims, so 
that particular grounds for rejection is discussed separately here. 

Briefly summarized, Figure 1 A of the Weber patent discloses nothing more than a typical 
personal computer, complete with a CPU, ROM and RAM memory, a bus, and input/output 
adapter connecting to a disk drive, a commimications adapter connecting to some form of 
network, a display adapter connecting to a display device, and a user interface adapter 
connecting to a keyboard, mouse, microphone, and speaker. 

The Examiner first cites Figure 1 A of the Weber patent against the second element of 
claims 38 and 42: 

tracker database means, analyzer database means, and issues database 
means all for storing digital information; [claim 38, second element] 

The law specifies that "means for" language covers "the corresponding structure ... 
described in the specification and equivalents thereof" (35 USC § 1 12, ^[6) The three databases 
recited in this claim language correspond to the tracker database 106, analyzer database 804, and 
issues database 1 12 which are all shown in overview m Figure 8 of the present application and 
discussed in the accompanying text. (The second element of claim 42 also recites a fourth 
database, "report template database means," which corresponds to the report template database 
204 also shown in Figure 8.) The details of the tracker database 106 are shown in Figure 9, 
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which illustrates a detailed structure for this database 106. No such teachings as to the 
organization of the tracker database are to be found in Figure 1 A of the Weber patent. The 
analyzer and issues (and report template) databases are also described generally in the present 
application as to what it is that they contain, and no comparable teachings are to be foimd in 
Figure 1 A of the Weber patent. Figure 1 A of Weber shows only a disk drive 20 and does not 
teach anything about what that disk drive contains or how any database that may be on that disk 
drive may be organized. 

Accordingly, the second element of the claim 38 clearly does not read upon Figure lA of 
the Weber patent, and neither does the corresponding second element of claim 42. 

The Examiner also cites Figure 1 A of the Weber patent against the second, third, and 
fourth elements of claim 40: 

audit report template means, residing within said report template database 
means, for defining all or portions of one or more audit reports; 

wherein the task definition means further comprises means for defining a 
list of audit report template means; and 

report generator means, connecting to said issues database means and said 
report template database means, for generating at least one audit report, guided by 
the task definition mean's listed report templates and by the issue identifying 
reports stored in the issues database. 

Figure lA discloses none of these elements of claim 40. Figure 1 A does not disclose any 
templates at all; it does not disclose any task defmition, particularly not one that includes a list of 
audit report templates; and it does not disclose any report generator. Figure 1 A of the Weber 
patent discloses only conventional computer hardware elements, no software elements. The 
claim language clearly does not read upon Figure 1 A of the Weber patent. 

Next, the Examiner cites Figure 1 A of the Weber patent against the third and fifth 
elements of claim 42: 

a network interconnecting said computers with said tracker database 

means; 

« * « * . 

9 
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analyzer means, residing within said analyzer database means, for defining 
the executable program steps needed to compute, from selected configuration 
information gathered from a single computer, a report identifying at least one 
issue relating to the computer; 

With respect to the third element of claim 42, the claim calls for a network that 
interconnects computers to a 'tracker database means." Weber's Figure 1 A does show one 
computer connecting to a network, but it does not show any "tracker database means," as was 
discussed above (a database containing hardware or software configuration information gathered 
from computers). 

With respect to the fifth element of claim 42, the claim calls for analyzer means defining 
executable program steps that can compute, from configuration data gathered from a computer, a 
report "identifying at least one issue relating to the computer." Figure 1 A of the Weber patent 
presents no such teachings. Thus, the claim language clearly does not read upon Figure 1 A of 
the Weber patent. 

Accordingly, the second element of claim 38 clearly does not read upon Figxjre 1 A of the 
Weber patent. The same may be said of the second, third, and fourth elements of claim 40 and of 
the second, third, and fifth elements of claim 42. 

iii. Claims 40 and 42 Do Not Read Upon Col. 6, lines 32-48 of the 
Desgrousilliers, et aL Patent 

The Examiner has cited the following passage taken from the Desgrousilliers, et al 

patent: 

In the preferred embodiment, a Macintosh computer with at least eight 
megabytes of memory and system 6.05 or newer is used as the platform for 
system 10. HyperCard stacks 15 (HyperCard is a trademark of Apple Computer 
Company) comprise a graphical interface product available from Apple Computer 
Company which runs on the Macintosh computer platform. HyperCard version 
2.0 or newer is preferred, and the HyperCard application memory size is 
preferably at least 5500 megabytes. These stacks are used as a "front end" to 
developmental system 10 and provide the primary interface for the user. Artificial 
intelligence inference engine 16 is used as the "back end" to developmental 
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system 10 and preferably comprises Nexpert Object, an artificial intelligence 
inference engine available from Neuron Data. Inference engine 16 is used to 
generate the test scripts, and to analyze the testing results once the testing has 
been completed, [col. 6, lines 32-48] 

This passage describes portions of Desgrousilliers, et a/.'s apparatus that assists a 
programmer in the testing of the detailed requirements for a computer program long before the 
computer program is actually written or coded, as has been fully explained. In particular, this 
passage describes the hardware and software program development environment (shown in 
Figure 1 of the patent) where the programmer works initially when preparing to test a program's 
requirements and where the programmer also works at the end when evaluating the results of 
such requirements testing. (The actual requirements testing is carried out on another platform 
shown in Figure 8, and not on the platform shown in Figure 1 and described in this passage.) 

This passage explains that a Macintosh computer is used as a software development 
platform for a developmental system 10 (Figure 1). To assist the programmer in developing the 
test data for use in later testing the requirements, this passage explains that programs (called 
"stacks" 16 in Figure 1) are written using Apple Computer's HyperCard program development 
system. This passage explains fiirther that an artificial intelligence inference engine 16 can then 
generate "test scripts." Following the testing (which is carried out on a different platform), 
some portion (not all) of the test results can be automatically processed into reports by that same 
artificial intelligence inference engine 16. This passage explains that the engine 16 is named 
Nexpert Object and is a software product of Neuron Data. 

This passage thus speaks of a software environment for developing test scripts to be used 
later in testing software requirements, a topic not addressed in the present application. This 
passage fiuther speaks of generating some reports from the results of testing software 
requirements, another topic not addressed in the present invention. The present invention has 
nothing whatsoever to do with the testing of the requirements for programs not yet written. 
Thus, this passage is irrelevant to the present invention. 
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1) The First and Second Elements of Claim 40 and the Sixth 

Element of Claim 42 Do Not Read Upon Desgrousilliers, 
etal 

The Examiner &st maintains tliat the following elements of the claims 40 and 42 read 
upon the above passage: 

report template database means for storing digital information; [first 
element of claim 40] 

audit report template means, residmg within said report template database 
means, for defining all or portions of one or more audit reports;^^ [second element 
of claim 40 and also sixth element of claim 42] 

The above passage taken fi-om the Desgrousilliers, et al patent and cited by the 
Examiner does not mention templates at all, and accordingly is not relevant to the claim 
language. The word 'template" does appear elsewhere in the Desgrousilliers, et al patent, but it 
is used only in the context of preparmg test data, not in the context of generating any kind of 
report (see, for example, col. 4, lines 39-41 of Desgrousilliers, etal, which were discussed fiilly 
above on pages 78 to 8 1). 

Accordingly, the first and second elements of claim 40 and the sixth element of claun 42 
clearly do not read upon this passage. 

2) The Seventh Element of Claim 42 Does Not Read Upon 

Desgrousilliers, et aL 

The Examiner also maintains that the seventh element of claim 42 reads upon the same 
passage set forth above: 

machine-readable task definition means for defining a list of one or more 
computers, a list of one or more analyzer means, and a list of one or more audit 
report template means; [seventh element of claun 42] 



The Examiner omitted two occurrences of the word "audit" from the second elements of claim 40 and 
from the sixdi element of claim 42 when quoting them in the Final Office Action mailed on 6/3/2004 (see page 26, 
lines 1-3 and page 29, lines 13-15). 
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But the Desgrousilliers, et al patent passage set forth above does not speak of any task other 
than that of testing program requirements. Program requirements testing involves the generation 
of test data, not the generation of lists of computers to be tested and lists of analyzers containing 
executable program steps that can test configuration information collected from the list of 
computers. And as to templates, it was explamed in the preceding paragraph that the 
Desgrousilliers, et al patent's use of the term ^templates" is to assist in developing test data for 
software requirements testing, not to define report formats as m the present application. 

Accordingly, the seventh element of clahn 42 clearly does not read upon this passage. 

j. Conclusion - The Elements of the Claims Are Not Rendered Obvious by 
Any Combination of the Weber and Desgrousilliers, et aL Patents 

In the discussion just presented, Applicant has carefiiUy considered every prior art 
passage cited by the Examiner and has discussed every rejected claim element individually, 
carefully analyzing the many combinations of the references that the Examiner has cited agamst 
the claims 3 1 to 42. The above discussion has demonstrated that all of the claims are patentable 
over ttiese various combinations. For all of the reasons stated above, all of the claims are now 
believed to be in condition for allowance. Their allowance is respectfully requested. 

£. Conclusion 

Applicants believe that the present application, as amended, is now in condition for 
allowance. Early and favorable reconsideration and allowance of this application, as amended, is 
respectfully requested. 

The Examiner is invited to contact the undersigned by telephone if it is felt that a 
telephone interview would advance the prosecution of the present application. 

The Commissioner is hereby authorized to charge any additional fees which may be 
required regarding this application under 37 C.F.R. §§ 1.16-1.17, or credit any overpayment, to 
Deposit Account No. 06-1450. Should no proper payment be enclosed herewith, as by a check 
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